Closed Bug 475164 Opened 14 years ago Closed 14 years ago

Starcraft Normal.ttf font doesn't work on Windows through @font-face

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: Gabri, Assigned: jtd)

References

Details

(Keywords: css2, css3, fixed1.9.1)

Attachments

(2 files)

I have done some test and I've seen that sometimes webfonts aren't loaded properly.

Here some link:
http://www.onsitus.it/css3/web-fonts/
http://css.flepstudio.org/css3/font-face.html
Flags: blocking1.9.1?
So, you didn't give steps to reproduce that allow us to tell whether this bug is fixed, but since I observe a problem that I think is what you're talking about, I'm going to change the description of this bug to match that one problem.

Steps to reproduce:
 1. load http://www.onsitus.it/css3/web-fonts/
 2. look at the third of the four samples, showing "Starcraft Normal.ttf"

Expected results: text rendered with font looks just like image above it (except a little bigger)

Actual results: text is in a basic serif font

I'm seeing this behavior on Windows, but it works as expected on Linux.


Does this accurately describe the problem you are reporting, or was there another font that didn't work for you?
Component: Style System (CSS) → GFX: Thebes
QA Contact: style-system → thebes
Summary: Some webfonts don't work → Starcraft Normal.ttf font doesn't work on Windows through @font-face
On windows, the example shown in http://css.flepstudio.org/css3/font-face.html (eldiablo.ttf) doesn't work in Firefox. Opera and Safari works as expected.
(In reply to comment #2)
> On windows, the example shown in http://css.flepstudio.org/css3/font-face.html
> (eldiablo.ttf) doesn't work in Firefox. Opera and Safari works as expected.

I filed that as a separate bug report: bug 475182, since it's cross-platform and therefore very likely a separate bug.
Not sure why this works on non-windows paltforms, but I think this bug is INVLAID.

Doesn't this:

src: url('http://www.onsitus.it/css3/web-fonts/Starcraft Normal.ttf');

need to be escaped as in:

src: url('http://www.onsitus.it/css3/web-fonts/Starcraft%20Normal.ttf');
If it's not escaped we'll fix it up exactly that way.
(In reply to comment #5)
> If it's not escaped we'll fix it up exactly that way.

Yes. It would seem that is not the issue.  I copied the entire page to my website and tried correcting the URI to one of the 2 properly escaped ones (both with the ' ' represented as '\ ' and '%20') and that made no difference.  Still works under Linux and fails under Windows.
A bit more testing reveled that the space in the filename was just a red herring.

The issue has nothing to do with the filename, but somehow with the contents of the font file itself.
These Microsoft-fonts (.EOT) also don't work on Firefox 3.1 (IE8 works properly) http://www.microsoft.com/typography/web/embedding/

Do you think we should file a new bug for this?
(In reply to comment #8)
> These Microsoft-fonts (.EOT) also don't work on Firefox 3.1 (IE8 works
> properly) http://www.microsoft.com/typography/web/embedding/
> 
> Do you think we should file a new bug for this?

Firefox/Opera/Safari do not support EOT fonts.  This is as intended, no need to file a bug.
Attached file simplified testcase
Simplified testcase

Steps:

1. Download testcase to a folder
2. Download the problem font to the same folder
http://www.onsitus.it/css3/web-fonts/Starcraft Normal.ttf
3. Open the locally-saved testcase

Result: the text shows in the default font rather than the downloaded font

The reason this occurs is that the font contains a zero-length version name record and the EOT header code is using the length to flag whether a name was found: 

http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/src/gfxFontUtils.cpp#1213

In general I think we should avoid loading fonts with funky problems like this but in this case, I don't think we need to be so picky since it's a relatively benign error (compared to a name record that with an offset past the end of the file for example).
Assignee: nobody → jdaggett
Status: NEW → ASSIGNED
Maintain a flag that goes to zero when all needed names have been found, rather than assuming length == 0 means name was not found.
Attachment #358808 - Flags: review?(vladimir)
One way to diagnose problems like this when they arise is to enable logging that ships in normal production builds.

1. Open console window
2. Change default directory to the where firefox.exe is located
3. Set environment vars below:

  NSPR_LOG_MODULES=userfonts:5,fontdownloader:5
  NSPR_LOG_FILE=userfonts.out

4. Run Firefox:

  ./firefox

5. Load pages with problem fonts.  

After the pages load, information about the font download will be saved in userfonts.out.  In this case, it looks something like:

0[723280]: userfonts (38df040) added (Starcraft) with style: normal weight: 400 stretch: 0
0[723280]: fontdownloader (38ddbc0) download start - font uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) referrer uri: (file:///C:/dev/webfontstest/starcraft.html)
0[723280]: userfonts (38df040) [src 0] loading uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) for (Starcraft)
0[723280]: fontdownloader (38ddbc0) download completed - font uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf)
0[723280]: userfonts (38df040) [src 0] failed uri: (file:///C:/dev/webfontstest/Starcraft%20Normal.ttf) for (Starcraft) error making platform font
0[723280]: userfonts (38df040) failed all src for (Starcraft)
0[723280]: userfonts (38df040) failed all faces, remove family (Starcraft)

The "error making platform font" means that the download succeeded (i.e. no access control restrictions or network errors) but for some reason the font could not be loaded.  This might be in Mozilla code that's doing font validation or it might be in OS code used to load the font.
Version: 1.9.1 Branch → Trunk
This should not block but it's fine to set wanted1.9.1.
Flags: blocking1.9.1? → wanted1.9.1?
Ready to be checked-in?
pushed
http://hg.mozilla.org/mozilla-central/rev/d08d06bdd4c9
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 358808 [details] [diff] [review]
patch, v.0.1, use a flag to detect when all names found

low impact, minor fix
Attachment #358808 - Flags: approval1.9.1?
Comment on attachment 358808 [details] [diff] [review]
patch, v.0.1, use a flag to detect when all names found

a191=beltzner
Attachment #358808 - Flags: approval1.9.1? → approval1.9.1+
Checkin-needed for 1.9.1 branch.
Keywords: checkin-needed
Flags: wanted1.9.1?
Depends on: 697320
You need to log in before you can comment on or make changes to this bug.