[Fontconfig] reminder: 2.11.0 to be released in next week
Raimund Steger
rs at mytum.de
Sun Aug 25 15:29:36 PDT 2013
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>
More information about the Fontconfig
mailing list