[Poppler-bugs] [Bug 49037] Noncompliance with Standard-14 fonts requirement in PDF specs

[bugzilla-daemon at freedesktop.org]

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

--- Comment #33 from suzuki toshiya <mpsuzuki at hiroshima-u.ac.jp> 2012-04-26 07:31:57 PDT ---
(In reply to comment #28)
> > (CreateFont() does not bring us to there, more hooks are needed),
> > it would be better than the juggling of pathname & familynames.
> 
> What else is required? The other option is to enumerate the fonts and do our
> own font matching like pango and firefox (the two examples I am familiar with).
> But I can't see that this is necessary for poppler.

I think the latter (our own font matching) is expected.

If we pass the familyname of available fonts to CreateFont(),
it would not be so troublesome. But if we pass the familyname
of unavailable fonts, the result is unreliable.

fontconfig checks the scripts supported by the fonts with
various informations, like, all defined character codepoints,
OpenType script/language tags, etc. But the charset/script/
language property we can pass to CreateFont() is too small;
only a codepage info in LOGFONT.lfCharSet.

LOGFONT.lfCharSet is often insufficient key to distinguish
the fonts for Japanese, Chinese, Taiwanese market.
When I specify GB2312_CHARSET to pickup Simplified Chinese font,
still Japanese fonts like "MS UI Gothic" can be listed by
EnumFontFamiliesEx() (nothing to say, Japanese fonts lack most
of simplified characters used in GB2312).

Thus, the font specification only by LOGFONT level is unsafe,
I think.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.