<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Improve size unparse?" href="https://bugs.freedesktop.org/show_bug.cgi?id=80873#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Improve size unparse?" href="https://bugs.freedesktop.org/show_bug.cgi?id=80873">bug 80873</a> from <a class="email" href="mailto:freedesktop@behdad.org" title="Behdad Esfahbod <freedesktop@behdad.org>"> Behdad Esfahbod</a> <pre>(In reply to <a href="show_bug.cgi?id=80873#c9">comment #9</a>) > (In reply to <a href="show_bug.cgi?id=80873#c8">comment #8</a>) > > Really? How about this: the FcCompareValueList is *only* called from > > FcCompare if both patterns have the element in question. Please check. I'm > > sure a missing item gets a score of zero and double-checked and > > triple-checked yesterday. > > You're right. but: > > (In reply to <a href="show_bug.cgi?id=80873#c6">comment #6</a>) > > Are you sure?! My understanding is that if either the pattern or font > > doesn't an element, that counts as a perfect match, ie. score 0: > > This is the problem. for example, one tries to find a font matching with > :size=12 say, it won't matches to the 12-ish sized (bitmap) fonts, because > the best matched score is always more than 1000. that's why we have certain > values in the cache and the pattern which is being targeted by matchers. in > that sense, I'm not sure if implementing <a class="bz_bug_link bz_status_NEW " title="NEW --- - Option to fc-match to NOT call FcConfigSubstitute / FcDefaultSubstitute?" href="show_bug.cgi?id=80929">Bug#80929</a> will gives us a corrrect > result. Ok, that's a fair and very good point, but that's independent of supporting ranges, right? I wish you had brought it up with me before. Looks like I broke that in 2008, and I can't justify why. I think we should revert that change instead: commit a5a384c5ffb479e095092c2aaedd406f8785280a Author: Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>> Date: Wed Dec 31 19:44:32 2008 -0500 [fcmatch] When matching, reserve score 0 for when elements don't exist Previously an index j was added to element score to prefer matches earlier in the value list to the later ones. This index started from 0, meaning that the score zero could be generated for the first element. By starting j from one, scores for when the element exists in both pattern and font can never be zero. The score zero is reserved for when the element is NOT available in both font and pattern. We will use this property later. This shouldn't change matching much. The only difference I can think of is that if a font family exists both as a bitmap font and a scalable version, and when requesting it at the size of the bitmap version, previously the font returned was nondeterministic. Now the scalable version will always be preferred. diff --git a/src/fcmatch.c b/src/fcmatch.c index 4d20a61..49dd0dd 100644 --- a/src/fcmatch.c +++ b/src/fcmatch.c @@ -317,7 +317,7 @@ FcCompareValueList (FcObject object, best = 1e99; bestStrong = 1e99; bestWeak = 1e99; - j = 0; + j = 1; for (v1 = v1orig; v1; v1 = FcValueListNext(v1)) { for (v2 = v2orig; v2; v2 = FcValueListNext(v2))</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>