Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond) Reporter
	Description • 17 years ago

OSX provides a Last Resort font with a graphical representation of each codepoint's range.  We should use this instead of our own missing-glyph drawing, because it looks nicer.

However, our drawing gives more info (the actual codepoint) -- so maybe this should be a pref?

	Stuart Parmenter
	Comment 1 • 17 years ago

imho, we should just make our stuff look nicer

	Smokey Ardisson (offline for a while; not following bugs - do not email)
	Comment 2 • 17 years ago

Using Last Resort is what's expected on the Mac and what other apps do (as well as what Gecko 1.8 does in some[1][2], but not all, cases).  In addition, in cases like this[3], Firefox would be using Last Resort in the titlebar but displaying the same exact text in the tab title (and page content) using GeckoBox, which seems ugly/wrong.

[1] Vlad's testcase from bug 364786: https://bugzilla.mozilla.org/attachment.cgi?id=271057
[2] Ahasuerus in an smontagu blog post: http://www.smontagu.org/blog/?p=291

[3] http://ml.wikipedia.org/

	Justin Dolske [:Dolske]
	Comment 3 • 17 years ago

(In reply to comment #0)

> However, our drawing gives more info (the actual codepoint) -- so maybe this
> should be a pref?

The "Last Resort" font does have the codepoint shown, although it's effectively hidden in the border such that you need to zoom in to see it.

	Jesse Ruderman
	Comment 4 • 17 years ago

The borders of the Last Resort glyphs contain the *range* of code points associated with the script, not the specific code point that was used in the document.

	Justin Dolske [:Dolske]
	Comment 5 • 17 years ago

Oops, right you are. I blame poor eyesight. :-)

	John Daggett (:jtd)
	Comment 6 • 17 years ago

One small note: there are actually codepoints for which the Last Resort font will not contain glyphs.  Examples: U+037B, U+037C, U+037D, Greek editorial symbols.  These are definitely exceptional cases, but it means that we need to test the Last Resort font codepoints before assuming there are glyphs.

	Justin Kerk
	Comment 7 • 16 years ago

Note that this font is now available for other OSes: http://www.unicode.org/policies/lastresortfont_eula.html

	Simon Montagu :smontagu
	Comment 8 • 16 years ago

On Linux it seems the font Just Works.

	Simon Montagu :smontagu
	Comment 9 • 16 years ago

I installed the font on Windows as well, and I notice that sometimes it is kicking in for scripts that I already had fonts for. I need to go back and recheck that that didn't happen on Linux, but I see no reason in principle why it shouldn't unless we add special code to make sure that it actually is used only as a last resort.

	Doug Sherk (:drs) (inactive)
	Comment 10 • 13 years ago

Marking this as WONTFIX because no decision has been made about whether or not to deploy this. Please re-open if you want to discuss more.

	Doug Sherk (:drs) (inactive)
	Comment 11 • 13 years ago

I didn't know what I was doing when I WONTFIX'd this, sorry.

	Jonathan Kew [:jfkthame]
	Comment 12 • 13 years ago

(In reply to Simon Montagu from comment #9)
> I installed the font on Windows as well, and I notice that sometimes it is
> kicking in for scripts that I already had fonts for. I need to go back and
> recheck that that didn't happen on Linux, but I see no reason in principle
> why it shouldn't unless we add special code to make sure that it actually is
> used only as a last resort.

Indeed, unless the font is somehow "hidden" from the normal font-list that we search when we need to do fallback for characters not available in the current CSS font-family, there's a risk that Last Resort may be chosen.

Mac OS X doesn't suffer from this because the Last Resort font is not included in the font list returned from NSFontManager, but if we're going to encourage people to install it on other OSes then this could become an issue for them - possibly affecting other applications that do fallback, too.

	Jonathan Kew [:jfkthame]
	Comment 13 • 13 years ago

Comment on attachment 271516 [details] [diff] [review]
use last resort font for missing glyphs

Marking Vlad's gfxAtsuiFont patch as obsolete; that code is long gone. If we want to use Last Resort for fallback in preference to hexboxes, we'll need a fresh patch. (And I think a different approach, based on extending gfxFontGroup::FindFontForChar, might make the most sense in the current codebase.)

	busi.bugzilla
	Comment 14 • 10 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #12)
> Indeed, unless the font is somehow "hidden" from the normal font-list that
> we search when we need to do fallback for characters not available in the
> current CSS font-family, there's a risk that Last Resort may be chosen.

I just had this issue. I was on the "Transliteration of Ancient Egyptian" Wikipedia page and text that should have been rendered in the Aegyptus font was instead a series of almost black blocks. Took me an hour to track down what was going on. I uninstalled the Last Resort font from my system and reloaded Firefox and the text was properly showing in the Aegyptus font.

Out of curiosity, why hasn't Firefox implemented a font fallback tweaking yet? There are many occasions where I shake my head when the fallback font chooses a glyph inside a word that was in a very different style from the font of the rest of the word and I think to myself "it should have used xxx font instead".

	John Daggett (:jtd)
	Comment 15 • 10 years ago

(In reply to busi.bugzilla from comment #14)
> (In reply to Jonathan Kew (:jfkthame) from comment #12)
> > Indeed, unless the font is somehow "hidden" from the normal font-list that
> > we search when we need to do fallback for characters not available in the
> > current CSS font-family, there's a risk that Last Resort may be chosen.
> 
> I just had this issue. I was on the "Transliteration of Ancient Egyptian"
> Wikipedia page and text that should have been rendered in the Aegyptus font
> was instead a series of almost black blocks. Took me an hour to track down
> what was going on. I uninstalled the Last Resort font from my system and
> reloaded Firefox and the text was properly showing in the Aegyptus font.
> 
> Out of curiosity, why hasn't Firefox implemented a font fallback tweaking
> yet? There are many occasions where I shake my head when the fallback font
> chooses a glyph inside a word that was in a very different style from the
> font of the rest of the word and I think to myself "it should have used xxx
> font instead".

When I experimented with using the Last Resort font as a replacement for hexcode boxes, it impacted overall page load times.

Under OSX, we use CoreText to select a suitable fallback in cases where commonly used fonts don't contain a glyph. This is done for performance reasons, it's too costly perf wise to do iterate over all fonts to determine a font. You can explicitly enable this using the pref below in about:config:

gfx.font_rendering.fallback.always_use_cmaps ==> true

This should pick up the Aegyptus font you were using. Another option would be to explicitly load a font for pages that use scripts rarely supported by common system fonts using @font-face.