If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

3.6.x windows regression wrt downloadable fonts and typekit

RESOLVED INVALID

Status

()

Core
General
RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: Tomcat, Unassigned)

Tracking

1.9.2 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
I noticed that when you load as example http://john.jubjubs.net/2010/07/27/books-ebooks/#comments on Firefox 3.6.8 new (without the cache) you see for a second the correct fonts and then something like resizing seem to happen and that messed up fonts occur. 

Also on Windows Firefox 4 Beta 2 - the web fonts on your blog are also ok - no messed up fonts.

-- Comment from John Dagget:
Hmmm, looks like I need to retract some of this.  Typekit is apparently sniffing the user agent string and shipping an entirely different font on Windows, on Windows it sends down a *TrueType* version of the font.  That said, I don't see any difference 3.6.3 ==> 3.6.8 on Windows 7, I'll test a bit more on XP.  Maybe Typekit was getting confused and shipping down the CFF font?  The screenshot attached below does look grayscale anti-aliased.  

Puzzling but guessing this is Typekit not us.

Cheers,

John

--
(Reporter)

Comment 1

7 years ago
so did more testing here and seems its the user agent string that cause the problem here. I tested again with Firefox 3.5.11 and it shows also the same problem like Firefox 3.6.3/3.6.8. Then i installed the "User Agent Switcher" Extension in Firefox 3.6.8 and changed the User Agent from the default Firefox to Internet Explorer 8 ID and works - no problems with the font.

Comment 2

7 years ago
(In reply to comment #1)
> so did more testing here and seems its the user agent string that cause the
> problem here. I tested again with Firefox 3.5.11 and it shows also the same
> problem like Firefox 3.6.3/3.6.8. Then i installed the "User Agent Switcher"
> Extension in Firefox 3.6.8 and changed the User Agent from the default Firefox
> to Internet Explorer 8 ID and works - no problems with the font.

So you see the right font and not the fallback Arial?  If so, that would imply they're doing (1) user agent sniffing on the server and (2) user agent sniffing in their javascript.  Typekit will ship EOT fonts to IE8 which won't work at all in Firefox.  So the javascript must be somehow recognizing this and shipping down a WOFF font instead.  Puzzling indeed...

Comment 3

7 years ago
Created attachment 461430 [details]
screenshot, win xp w/ user agent set to 3.6.17

So I confirmed a couple things.  With the user agent set to IE8, Firefox 3.6 displays the fallback font (Arial) *not* a poorly rendered version of the downloadable font.  This also occurs if the version is set to 3.7 (!) which means Typekit has set up some form of inclusive list that's pretty brittle.  Ditto for Minefield builds, we see fallback fonts.

The screenshot show Cleartype subpixel anti-aliasing so as far as the browser goes, everything is correct.  If there is a sequence of steps that somehow results in grayscale anti-aliasing we need to detail those better, I played around with resizing the window and didn't see anything incorrectly rendered.

Comment 4

7 years ago
Created attachment 461438 [details]
screenshot, win xp with no cleartype

Doh, first screenshot was taken with Cleartype enabled, this is *not* the default on Windows XP.  With Cleartype off by default most users will see text as seen in this screenshot which shows rendering with grayscale anti-aliasing.

Note that the behavior in FF4.0/trunk is different, we force Cleartype on by default for downloadable fonts (bug 504698).  Bug 566523 would also force it on by default for platform fonts.

Comment 5

7 years ago
Unless there's something we're clearly doing wrong here, I propose that this be closed as invalid.
(Reporter)

Comment 6

7 years ago
(In reply to comment #5)
> Unless there's something we're clearly doing wrong here, I propose that this be
> closed as invalid.

yup :), thanks !
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.