EUDC Font for Windows cannot be used as WebFont (@font-face)

RESOLVED INVALID

Status

()

Core
Layout: Text
RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: marwin.freutel, Unassigned)

Tracking

({fonts})

16 Branch
x86
Windows XP
fonts
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

73.79 KB, application/octet-stream
Details
(Reporter)

Description

5 years ago
Created attachment 671786 [details]
Test Page with EUDC fonts

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20121010144125

Steps to reproduce:

I create a EUDC font with the eudcedit.exe tool of windows xp
I saved that font to HMI.tte and rename it to HMI.ttf to use it as a truetype font (it is really a ttf!)
I use the character &#xe0000 till &#xe0002 for testing.
added a font-face with the truetype font.



Actual results:

Safari shows the icons with the "icon" style, FF not.


Expected results:

if the character set in installled locally and the "local" directive is used, than FF shows the EUDC chars.
(Reporter)

Updated

5 years ago
Keywords: fonts
(Reporter)

Updated

5 years ago
Priority: -- → P2
Timestamp: 17.10.2012 01:12:35
Error: downloadable font: table 'post': failed to parse table (font-family: "EUDC" style:normal weight:normal stretch:normal src index:0)
source: http://matti.no-ip.org/bug802088/HMI.TTF
Source Code:
@font-face {   font-family: "EUDC";   src: url("HMI.TTF") format("truetype"); }

Timestamp: 17.10.2012 01:12:35
Error: downloadable font: rejected by sanitizer (font-family: "EUDC" style:normal weight:normal stretch:normal src index:0)
source: http://matti.no-ip.org/bug802088/HMI.TTF
Source Code:
@font-face {   font-family: "EUDC";   src: url("HMI.TTF") format("truetype"); }

BTW: I had to fix the testcase (upper/lowercase of the TTF extensions).
Component: Untriaged → Layout: Text
Priority: P2 → --
Product: Firefox → Core
As indicated by the web-console messages above, the font is being rejected by the sanitizer because of an error in the 'post' table. Specifically, the font has a Format 2 'post' table (as expected for a Windows truetype font), but its numberOfGlyphs field is incorrect; it says 2259, while the 'maxp' table tells us that numGlyphs is 6402.

This is incorrect per the OpenType spec[1], and so OTS is correct to reject the font. Looks like the tool being used to create it is buggy.

A possible workaround would be to dump the font using ttx[2], and the rebuild it from the XML data generated; this will recalculate many of the tables in the font, and would probably result in a working ttf.

(BTW, although the font claims to have several thousand glyphs, I notice that it really only contains a handful - everything else is blank. Which suggests the tool that's creating it is not doing a very good/efficient job, and it means that if you used this font for anything other than those handful of characters, you'd probably see....nothing. I'd recommend trying more up-to-date tools.)

[1] http://www.microsoft.com/typography/otspec/post.htm
[2] http://sourceforge.net/projects/fonttools/
> Looks like the tool being used to create it is buggy.
The problem is that eudcedit.exe is shipped with Windows.
> (BTW, although the font claims to have several thousand glyphs, I notice that it really only contains a handful - everything else is blank. Which suggests the tool that's creating it is not doing a very good/efficient job, and it means that if you used this font for anything other than those handful of characters, you'd probably see....nothing. I'd recommend trying more up-to-date tools.)
It does not such a big because the font only covers PUA. (U+E000-U+F8FF)
(In reply to Masatoshi Kimura [:emk] from comment #3)
> > Looks like the tool being used to create it is buggy.
> The problem is that eudcedit.exe is shipped with Windows.

Sure. But given that it produces incorrect fonts (although they apparently work if installed in windows), people who want to deploy web fonts - rather than just use their private font locally - need to use a better tool, or else fix the resulting fonts (e.g. using ttx).

> > (BTW, although the font claims to have several thousand glyphs, I notice that it really only contains a handful - everything else is blank. Which suggests the tool that's creating it is not doing a very good/efficient job, and it means that if you used this font for anything other than those handful of characters, you'd probably see....nothing. I'd recommend trying more up-to-date tools.)
> It does not such a big because the font only covers PUA. (U+E000-U+F8FF)

Ah, yes - the cmap only maps PUA codepoints, even though many of the glyph names imply that they are normal Unicode characters. That's another bug in the tool - this will completely mislead any tool that tries to recover text from a PDF file, for example, on the basis of glyph names.

Note that the resulting TTF file is still 100K or so, when in fact it only needs to be about 2K. For someone deploying a web font, that would be a pretty good reason to avoid using it in this form.

So I'd suggest that if WinXP users want to use this tool for their own private, local purposes, that's fine; but if they want to deploy fonts on the web, they need to look elsewhere. It's out of date and produces hugely bloated files that are invalid according to Microsoft's own specification.
(Reporter)

Comment 5

5 years ago
Thank you for your quick response.
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> As indicated by the web-console messages above, the font is being rejected
> by the sanitizer because of an error in the 'post' table. Specifically, the
> font has a Format 2 'post' table (as expected for a Windows truetype font),
> but its numberOfGlyphs field is incorrect; it says 2259, while the 'maxp'
> table tells us that numGlyphs is 6402.
> 
> This is incorrect per the OpenType spec[1], and so OTS is correct to reject
> the font. Looks like the tool being used to create it is buggy.
> 
> A possible workaround would be to dump the font using ttx[2], and the
> rebuild it from the XML data generated; this will recalculate many of the
> tables in the font, and would probably result in a working ttf.
> 
> (BTW, although the font claims to have several thousand glyphs, I notice
> that it really only contains a handful - everything else is blank. Which
> suggests the tool that's creating it is not doing a very good/efficient job,
> and it means that if you used this font for anything other than those
> handful of characters, you'd probably see....nothing. I'd recommend trying
> more up-to-date tools.)
> 
> [1] http://www.microsoft.com/typography/otspec/post.htm
> [2] http://sourceforge.net/projects/fonttools/

Thank you for your quick reponse. I think to "repair" the font by the fonttools [2] is a good idea, if it even gets smaller. Unfortunately I could not generated a ttx.exe from the fonttools. Phyton2.6 did not generate a ttx.exe file and Phython 2.3 breaks the build. Do you have an idea? 

I think Microsoft will not fix the font creation of EUDC because we will not have the specified usecase. Actualy the "fixing" of the font will be best idea.
(Reporter)

Comment 6

5 years ago
I also converted the ttf file into a woff file. This has just a size of 13KB. Does this file correspond to the specification or does it contain empty glyphs? (s. Attachment).
Unfortunately currenty I do not have the tool to analyse and understand the architecture of the font files.
Converting the ttf to woff format will not help; this compresses the tables, but will not modify their content, so the inconsistency that is causing OTS to reject the font will still be there.

If you're not able to get the current fonttools release working (sorry, I haven't tried this on Windows, don't know anything about it), you might be able to make do with an older version, as I recall there used to be a precompiled Windows .exe available. The most recent one I see among the downloads on sourceforge seems to be at http://sourceforge.net/projects/fonttools/files/2.0b1/, but even though it's an old version it would probably work.

(Simply using ttx to "dump" the ttf to an XML file and then rebuilding it will not remove all the empty glyph slots, so the font will still be much larger than necessary - indeed, it may get bigger, as ttx will fill in all those missing glyph names - but I expect it should fix up the inconsistency that is causing @font-face usage to fail. The empty glyphs shouldn't actually be causing failure, they're just wasting space/bandwidth.)
(Reporter)

Comment 8

5 years ago
I try to ran the fonttools on the cygwin platform and now it is working on all browsers (except IE, uses EOT)!
So i need a tool for windows to convert the tte to a proper ttf font. I have posted the question in the microsoft forum.
Thank you for your help.
Resolving this as invalid - it's not a Firefox bug but a problem of the font tools.

(Incidentally, I'd expect you to see the same problem with Chrome as with Firefox, since it uses the same font-sanitizer library to validate downloadable fonts.)

If you want to produce and deploy your own fonts, I'd suggest you look into alternative tools (perhaps FontForge?) rather than relying on such an old (and presumably long-since unmaintained) tool, given that it is producing a poor-quality result.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.