[Fontconfig] reminder: 2.11.0 to be released in next week

[Raimund Steger]

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>
>
>
>