[Fontconfig-bugs] [Bug 72380] Never drop first font when trimming

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Dec 9 16:39:34 PST 2013


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

Behdad Esfahbod <freedesktop at behdad.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |freedesktop at behdad.org

--- Comment #2 from Behdad Esfahbod <freedesktop at behdad.org> ---
(In reply to comment #1)
> (In reply to comment #0)
> > We always advertise that FcFontMatch() returns the first item from
> > FcFontSort().
> 
> How is FcFontMatch() is relevant to that?

What I said.  We always advertise that FcFontMatch() returns the same font that
is at the top of the list of FcFontSort().  Pango relies on that for example. 
I believe Qt does too.


> I think it do more with the
> intelligent way than FcFontSort() because it checks the language coverage
> for the first font in the list.

Correct.


> >               This isn't true if the first font in the sort list has no
> > character coverage and trimming is enabled.  This happens with symbol.ttf
> > since it has no usable cmap table.  We should fix this by never trimming the
> > first font in the list.
> 
> I guess you are talking about FcFontSort() since FcFontMatch() doesn't have
> a feature to trim the list. so the suggestion may be to check the language
> coverage for the first font in the list as well as FcFontMatch() ?

No.  My suggestion is the other way around: to never trim the first font in
FcFontSort().  I'll attach a patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20131210/5bcacc43/attachment.html>


More information about the Fontconfig-bugs mailing list