[Fontconfig] reminder: 2.11.0 to be released in next week
Akira TAGOH
akira at tagoh.org
Fri Aug 23 21:47:30 PDT 2013
Doh. forgot to push it. done.
On Sat, Aug 24, 2013 at 5:47 AM, Raimund Steger <rs at mytum.de> wrote:
> Akira TAGOH wrote:
>>
>> Gotcha. should be fixed in git now.
>
>
> There seems to be no update in master... is it on another branch?
>
> Anyway, here's some local variables from yesterday's core:
>
>
> t at 1 (l at 1) program terminated by signal SEGV (no mapping at the fault
> address)
> Current function is FcConfigAdd
> 1367 sameBinding = position->binding;
> (dbx) up
> Current function is FcConfigSubstituteWithPat
> 1660 FcConfigAdd (&elt[object]->values,
> thisValue, FcTrue, l, r->u.edit->object);
> (dbx) print config->maxObjects, object, nobjs, r->u.edit->object
> config->maxObjects = 2
> object = 50
> nobjs = 50
> r->u.edit->object = 1050
> (dbx)
>
> -Raimund
>
>
>
>
>
>
>>
>> On Fri, Aug 23, 2013 at 5:01 PM, Akira TAGOH <akira at tagoh.org> wrote:
>>>
>>> Strange. that works for me.
>>>
>>> What's config->maxObjects?
>>>
>>> On Fri, Aug 23, 2013 at 6:51 AM, Raimund Steger <rs at mytum.de> wrote:
>>>>
>>>> Akira TAGOH wrote:
>>>>>
>>>>>
>>>>> Thanks for testing. that should works now...
>>>>
>>>>
>>>>
>>>> Confirmed.
>>>>
>>>> However, I get occasional coredumps.
>>>>
>>>> Using the snippet:
>>>>
>>>> <match target="font">
>>>> <test name="family"><string>Bitstream Vera Sans</string></test>
>>>> <edit name="BitstreamVeraSans1"><bool>true</bool></edit>
>>>> </match>
>>>> <match target="font">
>>>> <test name="family"><string>Bitstream Vera Sans</string></test>
>>>> <edit name="BitstreamVeraSans2"><bool>true</bool></edit>
>>>> </match>
>>>> <match target="font">
>>>> <test name="family"><string>Bitstream Vera Sans</string></test>
>>>> <edit name="BitstreamVeraSans3"><bool>true</bool></edit>
>>>> </match>
>>>> <match target="font">
>>>> <test name="family"><string>Bitstream Vera Sans</string></test>
>>>> <edit name="BitstreamVeraSans4"><bool>true</bool></edit>
>>>> </match>
>>>> <match target="font">
>>>> <test name="family"><string>Bitstream Vera Sans</string></test>
>>>> <edit name="BitstreamVeraSans5"><bool>true</bool></edit>
>>>> </match>
>>>>
>>>>
>>>> and executing fc-match several times in a row, i. e.
>>>>
>>>> bash-4.1$ (set -e;for i in {1..200};do fc-match "Bitstream Vera
>>>> Sans";done)
>>>>
>>>>
>>>> pretty reproducibly creates coredumps.
>>>>
>>>> In the debugger:
>>>>
>>>> t at 1 (l at 1) program terminated by signal SEGV (no mapping at the fault
>>>> address)
>>>> Current function is FcConfigAdd
>>>> 1367 sameBinding = position->binding;
>>>> (dbx) where
>>>> current thread: t at 1
>>>> =>[1] FcConfigAdd(head = 0xe4, position = 0x28, append = 1, new =
>>>> 0x8068648,
>>>> object = 1050), line 1367 in "fccfg.c"
>>>> [2] FcConfigSubstituteWithPat(config = 0x8062ee8, p = 0x8065ff0,
>>>> p_pat =
>>>> 0x8062860, kind = FcMatchFont), line 1660 in "fccfg.c"
>>>> [3] FcFontRenderPrepare(config = 0x8062ee8, pat = 0x8062860, font =
>>>> 0xfe1f0088), line 578 in "fcmatch.c"
>>>> [4] FcFontMatch(config = 0x8062ee8, p = 0x8062860, result =
>>>> 0xfeffe460),
>>>> line 712 in "fcmatch.c"
>>>> [5] main(argc = 3, argv = 0xfeffe4b8), line 192 in "fc-match.c"
>>>> (dbx)
>>>>
>>>>
>>>>
>>>> -Raimund
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> On Mon, Aug 5, 2013 at 7:32 AM, Raimund Steger <rs at mytum.de> wrote:
>>>>>>
>>>>>>
>>>>>> Akira TAGOH wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That should works as expected now. please test as well as usual
>>>>>>> matching rule since the logic was somewhat rewritten.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> There seems to be a regression.
>>>>>>
>>>>>> When testing the following rule:
>>>>>>
>>>>>> <match target="pattern">
>>>>>> <test name="family"><string>testfamily2</string></test>
>>>>>> <test name="pixelsize" compare="less"
>>>>>> qual="all"><double>100</double></test>
>>>>>> <edit name="family"
>>>>>> mode="append"><string>testfamily2_append</string></edit>
>>>>>> </match>
>>>>>>
>>>>>> with
>>>>>>
>>>>>> FC_DEBUG=1 fc-match testfamily2 |grep family:
>>>>>>
>>>>>>
>>>>>> the <edit> is applied at the wrong position, i. e. the position of the
>>>>>> 'family' match isn't retained if another <test> is inbetween.
>>>>>>
>>>>>> Raimund
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mon, Jun 17, 2013 at 9:25 PM, Raimund Steger <rs at mytum.de> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, June 11, 2013 09:59, Akira TAGOH wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> If there are not anything else we want to fix before releasing
>>>>>>>>> 2.11.0,
>>>>>>>>> please follow up on this mail otherwise I'll make one next week.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry- I know I should have tested this a lot earlier, but the
>>>>>>>> implementation of https://bugs.freedesktop.org/show_bug.cgi?id=59385
>>>>>>>> (intermixed <test> and <edit> elements in <match>,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cgit.freedesktop.org/fontconfig/commit/?id=d26fb23c41abd87422778bb38eea39f25ba3dc4a)
>>>>>>>> does not seem to exactly match Behdad's suggestion from his initial
>>>>>>>> mail:
>>>>>>>>
>>>>>>>> http://thread.gmane.org/gmane.comp.fonts.fontconfig/4607
>>>>>>>>
>>>>>>>> The suggestion in the mail is that:
>>>>>>>>
>>>>>>>> <match>
>>>>>>>> <test1>
>>>>>>>> <edit1>
>>>>>>>> <test2>
>>>>>>>> <edit2>
>>>>>>>> </match>
>>>>>>>>
>>>>>>>> is a shortcut for:
>>>>>>>>
>>>>>>>> <match>
>>>>>>>> <test1>
>>>>>>>> <edit1>
>>>>>>>> </match>
>>>>>>>> <match>
>>>>>>>> <test1>
>>>>>>>> <test2>
>>>>>>>> <edit2>
>>>>>>>> </match>
>>>>>>>>
>>>>>>>> i. e., test2 is only evaluated if test1 was successful.
>>>>>>>>
>>>>>>>> However the current implementation in head seems to generate two
>>>>>>>> unrelated
>>>>>>>> rules.
>>>>>>>>
>>>>>>>> If I make an example configuration like this:
>>>>>>>>
>>>>>>>> <match target="pattern">
>>>>>>>> <test name="family"
>>>>>>>> qual="first"><string>Helvetica</string></test>
>>>>>>>> <edit name="family" mode="append"><string>Helvetica LT
>>>>>>>> Std</string></edit>
>>>>>>>> <test name="pixelsize"
>>>>>>>> compare="less"><double>12</double></test>
>>>>>>>> <edit name="family" mode="prepend"><string>Lucida
>>>>>>>> Sans</string></edit>
>>>>>>>> </match>
>>>>>>>>
>>>>>>>> so that Helvetica LT Std is always acceptable for Helvetica, but
>>>>>>>> below
>>>>>>>> 12px Lucida Sans is preferred for the family, fontconfig instead
>>>>>>>> prepends
>>>>>>>> "Lucida Sans" to all patterns with a pixelsize below 12. So I'd have
>>>>>>>> to
>>>>>>>> write
>>>>>>>>
>>>>>>>> <match target="pattern">
>>>>>>>> <test name="family"
>>>>>>>> qual="first"><string>Helvetica</string></test>
>>>>>>>> <edit name="family" mode="append"><string>Helvetica LT
>>>>>>>> Std</string></edit>
>>>>>>>> <test name="family"
>>>>>>>> qual="first"><string>Helvetica</string></test>
>>>>>>>> <test name="pixelsize"
>>>>>>>> compare="less"><double>12</double></test>
>>>>>>>> <edit name="family" mode="prepend"
>>>>>>>> binding="strong"><string>Lucida
>>>>>>>> Sans</string></edit>
>>>>>>>> </match>
>>>>>>>>
>>>>>>>> instead.
>>>>>>>>
>>>>>>>> (Given I haven't made an error in my test) it's probably still an
>>>>>>>> improvement over 2.10 though.
>>>>>>>>
>>>>>>>>
>>>>>>>> Raimund
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Worringer Str 31 Duesseldorf 40211 DE home: <rs at mytum.de>
>>>>>>>> +49-179-2981632 icq 16845346 work: <rs at interface-ag.de>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Worringer Str 31 Duesseldorf 40211 DE home: <rs at mytum.de>
>>>>>> +49-179-2981632 icq 16845346 work: <rs at interface-ag.de>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Akira TAGOH
>>
>>
>>
>>
>
>
> --
> Worringer Str 31 Duesseldorf 40211 DE home: <rs at mytum.de>
> +49-179-2981632 icq 16845346 work: <rs at interface-ag.de>
--
Akira TAGOH
More information about the Fontconfig
mailing list