[Bug 10660] New versions of Fontforge generate marlett. ttf with incorrect available character sets field

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10660


Dmitry Timoshkov <dmitry at codeweavers.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




--- Comment #19 from Dmitry Timoshkov <dmitry at codeweavers.com>  2008-02-06 02:29:45 ---
http://sourceforge.net/mailarchive/forum.php?thread_name=200801311442.39548.s.wezel%40web.de&forum_name=fontforge-devel

George Williams writes:

> The other change is that in the old days if a font was displayed in
> "Symbol" encoding, then FontForge would save it with a 3,0 (symbol) cmap
> entry. That was a misunderstanding on my part. I assumed a "Symbol"
> encoding in Adobe's sense was the same as MicroSoft's, and that was
> wrong. So in modern FontForges the font is saved with a 3,1 (unicode)
> encoding instead. If you really want a symbol (3,0) cmap vector, use
> Generate($2, "sym.ttf", 0);
> instead.

TT_PLATFORM_MICROSOFT = 3
TT_MS_ID_SYMBOL_CS = 0
TT_MS_ID_UNICODE_CS = 1

So by (3,1) George means that modern Fontforge versions create a Unicode
charmap for marlett.ttf. But that's not the problem, the problem is that
Fontforge now sets Latin1 bit in the ulCodePageRange1 fileld in the OS2
TrueType header.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.