[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