[Fontconfig] reminder: 2.11.0 to be released in next week
Akira TAGOH
akira at tagoh.org
Sun Aug 25 20:48:56 PDT 2013
Thanks for catching this up. fixed.
On Mon, Aug 26, 2013 at 7:29 AM, Raimund Steger <rs at mytum.de> wrote:
> Akira TAGOH wrote:
>>
>> Doh. forgot to push it. done.
>
>
> Confirmed, seems to work.
>
> I've found another problem.
>
> With this config:
>
>
> <match target="font">
> <test name="family">
> <string>Bitstream Vera Sans</string>
> </test>
> <test name="family" target="pattern">
> <string>testfamily13</string>
> </test>
> <edit name="family" mode="assign"><string>testfamily13</string></edit>
> </match>
>
> the following command should result in a changed family name of the selected
> font, in this case "testfamily13". However, the edit isn't performed:
>
> sun2:fontconfig)fc-match 'Bitstream Vera Sans,testfamily13'
> Vera.ttf: "Bitstream Vera Sans" "Roman"
>
> In comparison:
>
> sun2:fontconfig)/usr/local/dist/stw/fontconfig-2.10.0/bin/fc-match
> 'Bitstream Vera Sans,testfamily13'
> Vera.ttf: "testfamily13" "Roman"
>
> (It works if I remove the second <test> -- the one against the pattern --
> above, or if I exchange the order of the tests.)
>
>
> -Raimund
>
>
>
>
>
>
>
>> 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>
>>
>>
>>
>>
>
>
> --
> 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