Gabriele Best [:Gabri] Reporter
	Description • 16 years ago

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

	David Baron :dbaron:
	Comment 1 • 16 years ago

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?

	Gabriele Best [:Gabri] Reporter
	Comment 2 • 16 years ago

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.

	David Baron :dbaron:
	Comment 3 • 16 years ago

(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.

	Bill Gianopoulos [:WG9s]
	Comment 4 • 16 years ago

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');

	David Baron :dbaron:
	Comment 5 • 16 years ago

If it's not escaped we'll fix it up exactly that way.

	Bill Gianopoulos [:WG9s]
	Comment 6 • 16 years ago

(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.

	Bill Gianopoulos [:WG9s]
	Comment 7 • 16 years ago

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.

	Gabriele Best [:Gabri] Reporter
	Comment 8 • 16 years ago

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?

	John Daggett (:jtd) Assignee
	Comment 9 • 16 years ago

(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.

	John Daggett (:jtd) Assignee
	Comment 10 • 16 years ago

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).

	John Daggett (:jtd) Assignee
	Comment 11 • 16 years ago

Maintain a flag that goes to zero when all needed names have been found, rather than assuming length == 0 means name was not found.

	John Daggett (:jtd) Assignee
	Comment 12 • 16 years ago

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.

	John Daggett (:jtd) Assignee
	Comment 13 • 16 years ago

This should not block but it's fine to set wanted1.9.1.

	Gabriele Best [:Gabri] Reporter
	Comment 14 • 16 years ago

Ready to be checked-in?

	John Daggett (:jtd) Assignee
	Comment 15 • 16 years ago

pushed
http://hg.mozilla.org/mozilla-central/rev/d08d06bdd4c9

	John Daggett (:jtd) Assignee
	Comment 16 • 16 years ago

Comment on attachment 358808 [details] [diff] [review]
patch, v.0.1, use a flag to detect when all names found

low impact, minor fix

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 17 • 15 years ago

Comment on attachment 358808 [details] [diff] [review]
patch, v.0.1, use a flag to detect when all names found

a191=beltzner

	Gabriele Best [:Gabri] Reporter
	Comment 18 • 15 years ago

Checkin-needed for 1.9.1 branch.

	John Daggett (:jtd) Assignee
	Comment 19 • 15 years ago

pushed to 1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cad700a6b3c3