Open Bug 459007 Opened 12 years ago Updated 6 years ago

Firefox picks Zapfino for 'LATIN SMALL LIGATURE FF', which looks ridiculous in a paragraph

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set
minor

Tracking

()

People

(Reporter: jruderman, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(3 files)

Attached file testcase
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081007 Minefield/3.1b1pre

In the first paragraph of http://www.thatone08.com/, Firefox's rendering of the word "offers" is ridiculous: the 'ff' is much larger than the surrounding text.  I think this happens because Firefox picks Zapfino, and Zapfino tends to be large.  Safari's rendering is more sane.
Attached image screenshot
Attached image safari screenshot
The page uses a hard coded U+FB00 LATIN SMALL LIGATURE FF.

It looks like Safari is doing some kind of compatibility decomposition, since Find in Page "offers" fails in firefox but succeeds in Safari.
I don't know about you, but I think the way firefox renders it looks awesome!

(Yes, this is weird, but I bet we're just pulling the first font that has that glyph.)
I just ran into this bug, from a scientific paper generated by Acrobat SaveAsXML.

http://www.usenix.org/event/hotpar09/tech/full_papers/ceze/ceze_html/

If this publishing method and tool become popular, it'd be *really* nice to have this bug fixed.  The page above looks pretty silly.  Is a fix possible?
Nowadays, I see this quite regularly on the pages of http://www.guardian.co.uk/
Their 'comment is Free' section seems most affected. Dunno if it is some setting in their CMS interface, or the result of Copy/pasting from Word docs.

example:
http://www.guardian.co.uk/commentisfree/2009/mar/27/g20-globalrecession
Duplicate of this bug: 509182
This has little to do with a bug. For each character in the text, Firefox (or any browser) tries to locate it in the requested font or fonts (CSS) and if it fails, it will try to locate it in a font that has the same characteristics (italics, bold) and if that fails too, it will try to locate the Unicode codepoint in some of the default Unicode fonts (not all installed fonts on a particular system are searched).

If somewhere along the process it finds a glyph for that particular codepoint (here it finds it in Zapfino, apparently) it will render that glyph. The result may not always be desirable. 

If it cannot find the glyph anywhere, the browser can decide to use Unicode Normalization and try again (it would find twice the letter F after normalization). If that still doesn't help, it will display the Replacement Glyph (a question mark).

The result of this process is naturally dependent on the installed font-faces and cannot always be predicted. A HTML designer, if it wants to use LIGATURE FF instead of twice letter F, he probably has a reason to do so. It is up to the browser to render it. It is up to the machine where the browser runs to have the fonts installed. 

This is not a bug, it is the natural result of finding the best match for the ligature FF (I cannot change status though, someone else will have to change this to "NOT A BUG").
(In reply to comment #9)
> This has little to do with a bug. For each character in the text, Firefox (or
> any browser) tries to locate it in the requested font or fonts (CSS) and if it
> fails, it will try to locate it in a font that has the same characteristics
> (italics, bold) and if that fails too, it will try to locate the Unicode
> codepoint in some of the default Unicode fonts (not all installed fonts on a
> particular system are searched).
> 
> If somewhere along the process it finds a glyph for that particular codepoint
> (here it finds it in Zapfino, apparently) it will render that glyph. The result
> may not always be desirable. 
> 

Oh?  And if when looking up a glyph for, say, the "fi" ligature Firefox were to, say, find and render the skull and crossbones glyph from Wingdings, would you stand by this argument?
(In reply to comment #9)
> This is not a bug, it is the natural result of finding the best match for the
> ligature FF (I cannot change status though, someone else will have to change
> this to "NOT A BUG").

Well then I would say that this is a problem with the font-selection algorithm in Firefox as Safari renders it correctly without using Zapfino on the same system with the same fonts installed.
> say, find and render the skull and crossbones glyph from 
> Wingdings, would you stand by this argument?

Yes, it's an interesting point, but let me explain:

The Wingdings is never used, that way, simply because it is an ASCII-based font. Try set a font to Wingdings and you will see normal Latin. Nothing stops you from creating a font that supports Unicode and has a glyph for A that looks like B, but I don't need to expand on the confusion such font would cause.

Firefox uses internally a mapping from Wingdings / Webdings etc to the known Unicode characters. To see the smiley you don't type the J (it will render as J) but the unicode U+263A (as ☺ in HTML). On my system, the Wingdings, even if specified, is not selected, Arial is used (which contains the smiley).

See: https://developer.mozilla.org/en/Mozilla_Web_Developer_FAQ#Why_aren.e2.80.99t_symbol.2fdingbat_fonts_working.3f

Note: All IE versions, including IE8 still do this wrong and against the CSS standard which is clear on the point of using Unicode fonts and mapping others.

> this is a problem with the font-selection algorithm in Firefox
> as Safari renders it correctly without using Zapfino

Very well possible. Font selection algorithms are very complex. It is impossible to write a specific case for each codepoint for each selected font for each local system installation. I'm not surprised this works better with Safari as that was originally created for the Mac. Wonder how Chrome would, because that uses mixed Firefox / Safari code. Your FF LIGATURE looks fine on Windows systems (well, at least mine, but I have a ton of fonts...).

It seems to me that Zapfino is a Script style font and Firefox somehow ignores the script-bit (or it isn't in the font) or fails to find a font that closer matches the surrounding font.
John,

What can we do about this? Other OS X applications do a much better job choosing font substitutes than we do.

Compare the rendering of this page with the rendering in Safari or Chrome:
http://people.mozilla.com/~jmuizelaar/ligature.html
(In reply to comment #14)
> John,
> 
> What can we do about this? Other OS X applications do a much better job
> choosing font substitutes than we do.
> 
> Compare the rendering of this page with the rendering in Safari or Chrome:
> http://people.mozilla.com/~jmuizelaar/ligature.html

Well, in general Webkit does cruder font fallback, in this case it's simply choosing Lucida Grande as the fallback font.  Gecko looks at all fonts that have a glyph for this character and roughly match the desired style.  For ties, it picks the last font, so in this case users with only default fonts end up with Zapfino (I end up with a locally installed font).

I think the solution would be to check a "default" font (e.g. Lucida Grande) before doing system fallback, this would give us more "Safari-like" behavior on the Mac.  It would probably make sense to have an explicit blacklist for fonts that shouldn't be included in system font fallback (e.g. Zapfino!).

Testcase showing alphabetic presentation form fallback for a variety of fonts:

http://people.mozilla.org/~jdaggett/tests/presentationligs.html

One interesting aspect of Jeff's testcase is that Safari picks the bold face of Lucida Grande for fallback from Charcoal CY, since Charcoal CY is a family with only a bold face.
Fwiw, here is how WebKit latest nightly and Safari render jef's testcase:
http://dev.l-c-n.com/_b/ligatures_webkit.png
Not sure if that is Apple Chancery or some other one.
(In reply to comment #16)
> Fwiw, here is how WebKit latest nightly and Safari render jef's testcase:
> http://dev.l-c-n.com/_b/ligatures_webkit.png
> Not sure if that is Apple Chancery or some other one.

Yes, that's Apple Chancery.

Clearly they're using some font attributes (serif/sans/script/...?) to try and pick a "suitable" fallback, whereas Gecko doesn't pay attention to those things. We should try to improve this. I note from the screenshot that Webkit doesn't manage to pick a serif face for fallback in line 2, even though OS X includes several serifed faces that support the ff and ffi presentation ligatures.

(More generally, web authors should NOT normally be using characters such as this in their pages. They should simply write the logical underlying text; ligatures are the responsibility of the font rendering system - AAT, OpenType, etc.)
Duplicate of this bug: 577693
You need to log in before you can comment on or make changes to this bug.