718513 - Synthetic bold does not work with src:local(...) @font-face declarations under DirectWrite

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Mick P.]

I tried to leverage @font-face yesterday to address the problem of some Windows boxes not having a suitable Unicode font installed. In 2012 it would be nice if Unicode was a guarantee for a web client, but it is not. Font-face could be a fix for this dilemma where implemented, but there are hurdles. Firefox was one.

I don't know if @font-face is ready for non-trivial (read: not cosmetic) applications, but please consider the following.

Under Firefox the following CSS is not equivalent to its absence:

@font-face {
 src: local("Arial Unicode MS");
 font-family: "Arial Unicode MS"; 
} 

Whether or not the CSS specification says this should be the same as simply specifying "Arial Unicode MS" in the font-family of any style... it seems like it should be!

There are probably more issues. However, with Firefox9 this will yield you a font which is immune to font-weight declarations. I'd guess its immune to font-style as well, but in my tests I am pretty sure I saw italics being handled correctly. The CSS rule seemed to have unexpected side-effects (seemingly more restrictive) in Firebug, as if the use of @font-face takes Firefox down an alternate execution path.

Arial Unicode MS is an enormous font (~14MB gzipped) and does not come in bold/italic versions for that reason. In general it seems that web site visitors would be better served by a single font download versus having to download multiple versions of a font. And therefore priority should be given to the case where bold/italic/bold+italic is synthesized. 

From a user perspective I would prefer to be able to disable the automatic download of bold/italic/other embedded fonts. Concern should also probably be given to dial-up like connections. Some visual cue that a font is being downloaded would aid viewers of foreign language sites who do not desire the readability of the foreign fonts, and allow download of large/candy fonts to be canceled, and communicate to the reader that the website is not yet fully loaded because it depends upon an outstanding font download.

Disclaimer: consider Arial Unicode MS an example. It is a font requiring a license, but it comes preloaded on most Windows installations because it is part of the MS Office sampler. Without it, its probably realistic to say Windows is not a Unicode capable OS, which is pretty outrageous. Microsoft should have this font freely available on the web for web pages at the very least... if not part of a future Windows Update. 

Every site downloading Unicode fonts is probably not the best thing for users either. Unicode symbols are generally better than images because they will be rendered by the same rendering engine, even if they are less portable. They result in a more consistent presentation. 

Its a can of worms. But I wonder if there is any use for @font-face beyond quirky fonts. The same need for Unicode symbols applies to foreign language fonts.

Comment 1

[Josh Matthews [:jdm]]

This might belong in Layout: Text instead; I'm not really sure.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Layout:Text is the right place, but I really can't figure out what the issue is from reading comment 0.  Mick, a clear description of what behavior you expected and what behavior you saw instead, combined with the exact testcase you used, would be helpful.

Comment 3

[John Daggett (:jtd)]

Mick, for a bug reporting system like bugzilla you need to log clear *bugs* with steps to reproduce, and separate each case into a different bug.

I wrote two testcases for Arial Unicode MS, one with local and one without, and they both render identically:

http://people.mozilla.org/~jdaggett/tests/arialunicode.html
http://people.mozilla.org/~jdaggett/tests/arialunicode-local.html

If you have spotted issues with how font-weight is handled, please log it as a separate bug and include the steps to reproduce the problem, including actual testcases or URLs that reproduce the problem you're seeing.

Comment 4

[Mick P.]

John, I am aware of this, but that is more work than I was up to. 

For me your test cases (good job BTW) exhibit the behavior described in the top post. Windows 7 Firefox 9. 

I don't see the need to create another bug report. You are welcome to if my contribution is insufficient. 

Again to be clear. Font-weight is not working in arialunicode-local.html (comment 3) but is in arialunicode.html (not using @font-face)

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Mick P. from comment #4)

> Again to be clear. Font-weight is not working in arialunicode-local.html
> (comment 3) but is in arialunicode.html (not using @font-face)

It's not clear what you mean by "Font-weight is not working in arialunicode-local.html" .... that example does not include any use of font-weight.

Comment 6

[Mick P.]

You can add font-weight to the example. Or you can use Firebug to add it. Try it.

Comment 7

[Jonathan Kew [:jfkthame]]

It really does save time and confusion if you provide an actual testcase for the problem you're seeing. A statement like "You can add font-weight to the example" is not as helpful.... does that mean adding it as a descriptor within the @font-face declaration; to the properties of an element; in both places; or what, exactly....?

Nevertheless....

It turns out there is an issue that relates to src:local(...) usage under DirectWrite, so I'm morphing the summary of this bug to reflect the real problem.

When @font-face is used to create a custom font family that does not include a face with a "bold" font-weight, and then this family is used for an element that _does_ have a bold weight, we're supposed to apply synthetic emboldening to the face. This works with fonts loaded from files using src:url(....), and works for src:local(....) on most platforms, but under DirectWrite we fail to apply any synthetic bolding, because the aSimulations parameter is ignored at http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxDWriteFontList.cpp#433.

Note that if you disable hardware acceleration, or start Firefox in Safe Mode, the problem will go away. (This is a good clue that the DirectWrite font subsystem is a key factor in the issue.)

Testcase and patch coming.

Comment 8

[Jonathan Kew [:jfkthame]]

(In reply to Mick P. from comment #0)
> Under Firefox the following CSS is not equivalent to its absence:
> 
> @font-face {
>  src: local("Arial Unicode MS");
>  font-family: "Arial Unicode MS"; 
> } 
> 
> Whether or not the CSS specification says this should be the same as simply
> specifying "Arial Unicode MS" in the font-family of any style... it seems
> like it should be!

No, it is not in general correct to assume that "the following CSS [should be] equivalent to its absence":
  @font-face {
    src: local("Some Available Font Name");
    font-family: "Some Installed Font Name";
  }
It happens that this should be true (aside from the bug here) for Arial Unicode MS, but it would not hold for families where there are both regular and bold faces installed. The reason is that without the @font-face declaration, the font family will choose the best match from among its available weights, whereas using @font-face like this defines the family as having just _one_ face, and so "bold" elements will apply a synthetic bolding effect instead of using a true bold font.

There are other more subtle issues as well that can make this not true even for a single-face family, depending on the face's style attributes (if the single face that exists is inherently bold and/or italic, and you fail to reflect this in the proper @font-face descriptors, the result will behave differently when used in elements with these properties).

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: testcase for synthetic bold using Papyrus

This testcase compares Papyrus (which I think is standard on Win7) accessed directly with font-family, and loaded via src:local. As there is just a single Regular face of Papyrus, the <b> element should use synthetic bold in both cases; however, under DWrite the src:local() version does not show any bolding.

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: patch, if aSimulations requires synthetic bold, replace the font face with a copy that has this simulation enabled

This seems rather ugly, but appears to work. Unfortunately, DWrite doesn't offer a simple API to _modify_ the simulations of a font face once it's created, or to directly create a new face with different simulations from an existing one.

Comment 11

[Bas Schouten (:bas.schouten)]

Comment on attachment 589524 [details] [diff] [review]
patch, if aSimulations requires synthetic bold, replace the font face with a copy that has this simulation enabled

Review of attachment 589524 [details] [diff] [review]:
-----------------------------------------------------------------

If this solves the issue, let's do it.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: reftest based on the Papyrus testcase

This assumes the availability of the Papyrus font, but should pass harmlessly on platforms where it's not present. Pushing to tryserver to check for surprises...

Comment 13

[John Daggett (:jtd)]

(In reply to Mick P. from comment #4)
> John, I am aware of this, but that is more work than I was up to. 
> 
> For me your test cases (good job BTW) exhibit the behavior described in the
> top post. Windows 7 Firefox 9. 

Mick, sorry, I still don't understand this, under Windows 7 the two testcases in comment 3 render differently for you?  If so, that's a different bug than the bolding issue.

Comment 14

[Jonathan Kew [:jfkthame]]

Pushed patch & reftest to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/92395111938e
https://hg.mozilla.org/integration/mozilla-inbound/rev/d05a2f422e7d

Comment 15

[John Daggett (:jtd)]

(In reply to John Daggett (:jtd) from comment #13)
> (In reply to Mick P. from comment #4)
> > John, I am aware of this, but that is more work than I was up to. 
> > 
> > For me your test cases (good job BTW) exhibit the behavior described in the
> > top post. Windows 7 Firefox 9. 
> 
> Mick, sorry, I still don't understand this, under Windows 7 the two
> testcases in comment 3 render differently for you?  If so, that's a
> different bug than the bolding issue.

The two testcases in comment 3 render identically on Windows 7 (Arial Unicode MS is not installed by default so the text is rendered with a fallback font) and under Windows XP (where the text is rendered with Arial Unicode MS).

Comment 16

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/92395111938e
https://hg.mozilla.org/mozilla-central/rev/d05a2f422e7d

Comment 17

[Mick P.]

Glad to be of help. I maintain software myself / am aware of the trade-offs of reporting. And aware that any reporting is better than none.

@Comment 13: They render differently if the element using the font is emboldened somehow. Windows 7, Firefox9, a local version of the font is available.

@Comment 8: As what you've quoted states, I'm aware the CSS spec may imply differences, but in a default scenario where there is nothing else but substitution going on, either the default behavior SHOULD be made to reflect the font-face spec retroactively, or the font-face spec should be bent to adhere to the legacy behavior. Having two different methodologies represents a schism that doesn't serve either purpose.

That said, if transparency cannot be reconciled, authors need more control over this so font-face can be used in a straightforward way to provide instant accessibility to a document. Therefore I would recommend CSS extensions to @font-face, like -moz something or allow additional values to font-style/weight like font-weight:transparent (do whatever Firefox would do with a local font normally whether already local or local once downloaded from the remote source)

An extension to explicitly demand synthetics might be desirable too. It would also be very handy if Firefox would assume if it has a font cached with the same name then it should use that, its bad for every website to be serving up Arial Unicode MS when there is an almost guarantee if you have a font with that name downloaded already its the same font. Seeing the same font downloaded might also encourage users to seek out/install a font to their computer locally. Would be nice if Mozilla could reach out to parties in order to standardize the serving up of core fonts somehow.