Strange. that works for me.
What's config->maxObjects?
On Fri, Aug 23, 2013 at 6:51 AM, Raimund Steger <rs@xxxxxxxx> 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@1 (l@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@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@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx>
>>>>> +49-179-2981632 icq 16845346 work: <rs@xxxxxxxxxxxxxxx>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Worringer Str 31 Duesseldorf 40211 DE home: <rs@xxxxxxxx>
>>> +49-179-2981632 icq 16845346 work: <rs@xxxxxxxxxxxxxxx>
>>
>>
>>
>>
>
--
Akira TAGOH
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
