[Fontconfig-bugs] [Bug 80873] Improve size unparse?

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80873

--- Comment #10 from Behdad Esfahbod <freedesktop at behdad.org> ---
(In reply to comment #9)
> (In reply to comment #8)
> > 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 comment #6)
> > 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 Bug#80929 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 <behdad at behdad.org>
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))

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20140816/b3775a45/attachment.html>