776284 - Automatic font selection for Cuneiform unicode block not working on Windows 7

Status: NEW

(Core :: Graphics: Text, defect, P3)

Description

[Tisza Gergő]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

On Windows 7 Firefox does not display cuneiform letters unless the font is set manually.

Steps to reproduce:
1. install font file from http://users.teilar.gr/~g1951d/Akkadian301.zip
2. compare display of e. g. U+1203B with and without Akkadian font-family explicitly set (see linked test page)


Actual results:

The character only displays when the font family is explicitly set.


Expected results:

Firefox should automatically select a font which supports the character.

Comment 1

[Tisza Gergő]

I've been told that this works correctly on XP/Vista.

Comment 2

[Loic]

There is a regression on Win 7 indeed.

Mozregression range:

m-c
good=2012-03-09
bad=2012-03-10
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=08809a43e082&tochange=3fdc1c14a8ce

m-i
good=2012-03-08
bad=2012-03-09
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=45d1588c2c71&tochange=2f21548bcbc4

Suspected bug:
Bug 705594 - optimize system font fallback

Comment 3

[Jonathan Kew [:jfkthame]]

As a workaround for the problem, try setting gfx.font_rendering.fallback.always_use_cmaps to true in about:config.

Personally, I think we should automatically fall back to that approach if the "optimized" fallback path fails to find a font.

Comment 4

[John Daggett (:jtd)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> As a workaround for the problem, try setting
> gfx.font_rendering.fallback.always_use_cmaps to true in about:config.
> 
> Personally, I think we should automatically fall back to that approach if
> the "optimized" fallback path fails to find a font.

Having a "search for all fonts" path in our code leads to unacceptable hang times as documented by the telemetry data.  For most users, if a font isn't found by the hard-coded font fallback or DirectWrite fallback then that implies that a font doesn't exist and it would be pointless to troll through all system fonts looking for one.

So the question is really how we can avoid "search for all fonts"-like solutions and still assure that fonts such as this one are indeed picked up.  It sucks that the DirectWrite doesn't seem to be correctly handling this.

For now, the workaround is to enable the pref above.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to John Daggett (:jtd) from comment #4)

> Having a "search for all fonts" path in our code leads to unacceptable hang
> times as documented by the telemetry data. 

I don't think this is a fair summary of the situation at this point. That issue, and the telemetry you're referring to, predated the introduction of the DirectWrite-based fallback path.

Prior to the changes that introduced the hard-coded fallback and DW fallback, it was quite common for pages (e.g. those with a bunch of other-language links) to hit system fallback, which had the potential to hang temporarily. That was the situation that was judged unacceptable.

Now that we have those fallback shortcuts, I think we should consider restoring the "search all fonts" path as a last-resort fallback, used *after* we've tried the hard-coded fallbacks and the DW path. The expectation is that the vast majority of fallback needs will be covered by those code paths - indeed, they must be or we'd be seeing a lot more "can't find a font" problems - and therefore it will be *much* rarer that we need to take the global-search path with the potential for a (temporary) hang. The only users who would hit that path - which doesn't mean they'd _necessarily_ see a hang, only that they _might_ see one - will be those who are currently seeing missing-char hexboxes because DW can't find a font.

IMO, it'd be better to risk the occasional temporary hang in that situation - which will now be FAR rarer than before - than to expect such users to discover and tweak a pref in about:config.

(Moreover, IIRC enabling that pref means we'll use the search-all-fonts path _instead of_ the DW fallback path, which means users who turn it on will have a higher risk of hitting the hang than if we try the DW path first and _then_ the search-all-fonts one.)

Comment 6

[John Daggett (:jtd)]

For the default set of fonts that ship with Windows 7, the hard-coded
fallback fonts will cover all of the codepoints supported by the union
of the coverage maps of those fonts.  If a font for a given codepoint
isn't found, the 99% case is that no font exists for that codepoint. 
Searching all fonts isn't going to find one but it *will* cause hangs
for some users.

With the change you advocate, simply navigating to 'wikipedia.org'
will *always* result in "search all fonts" code getting hit, because
the default wikipedia page includes lots of scripts that are
unsupported by standard platform fonts.

Not surprisingly, the hangs always occur the first time any sort of
"search all fonts" code is called.  Our goal needs to be to eliminate
the use all code paths that could potentially hit a synchronos,
first-time loop like this that iterates over all fonts.

Yes, there are users who install fonts for specific scripts not
covered in the default set and I really want Firefox to automatically
find those fonts.  But we can only do this in a way that assures the
"search all fonts" code isn't hit synchronosly on the main thread.

Comment 7

[u279076]

Hey Jonathan, is this bug still valid?

Comment 8

[Jonathan Kew [:jfkthame]]

I presume so (without actually re-testing), as I don't think we've done anything to address it.