502795 - CoreText enabled builds: Odd character substitutions with letter-spacing & @font-face

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[philippe (part-time)]

Attachment: screenshot from URL

STR
1. build Minefield with GCC 4.2, 10.5 sdk and ac_add_options --enable-coretext
2. visit http://craigmod.com/journal/font-face/
3. notice the strings of text that should display in 'small-caps': characters are all wrong.

I tracked this down to the use of 'letter-spacing:1px'.
While testing, I encountered a similar issue with Fontin. In that case, the string was supposed to display in bold italic. The font face was specified, but the font was missing (not available on the server) - forcing the browser to artificially bold the face.

minimised testcase: http://dev.l-c-n.com/css3_font-face/ac_cl.html
The last block of text shows the issue.

Comment 1

[Jonathan Kew [:jfkthame]]

Confirmed that I can reproduce this (yuck!) with my trunk build, when using Core Text. I'll look into it.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: avoid using CTFontCreateCopyWithAttributes to disable ligatures because it fails with privately-activated download fonts

The bug occurs because we're using the (undocumented) kPrivateATSFontContextPrivate to activate downloaded fonts without them becoming visible to other documents within the browser instance. Unfortunately, using this appears to prevent CTFontCreateCopyWithAttributes creating a new Core Text font instance from an existing one, which was how we turn off ligatures when letterspacing is requested. As a result, the line layout for letterspaced downloaded fonts ends up getting done using glyph IDs and metrics from a system fallback font (typically Lucida Grande), even though we still end up drawing with the downloaded font.

The fix is to use the original ATS font reference, not the CTFont descriptor, when creating the no-ligatures instance; this appears to be the only "safe" way to instantiate a new version of such a privately-loaded font.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 387239 [details] [diff] [review]
avoid using CTFontCreateCopyWithAttributes to disable ligatures because it fails with privately-activated download fonts

Seems like we need a reftest here

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: reftest for the CoreText / @font-face / letter-spacing failure

This test fails under Core Text without the above patch, and passes with it. It depends on using a linked font (Ahem) whose character-to-glyphID mapping differs from the fallback (Lucida Grande) that was being used to get glyph IDs during layout.

Note that with unpatched Gecko, it is possible for the test to display an alert from Apple Type Services:

  Minefield.app wants to use the font “MarkA”.
  This font is not installed. Allow Minefield.app to use this font?

with options "Don't Allow" or "Allow". Do *not* click "Allow", as that leads to a false test pass.

I think this behavior depends on whether the ATS system has "seen" the local copy of MarkA.ttf in some way, in which case it may offer to auto-activate it at this point. Clicking Allow would let the test (incorrectly) pass; clicking Don't Allow, which corresponds to the behavior for an arbitrary linked font that is not present on the local disk, will make the test fail. If reftest were running unattended on a unit test box, I assume this would eventually lead to a timeout failure (which would be the correct result in that situation).

Once the patch here is applied, the downloaded copy of the font is correctly used, and the auto-activation alert does not appear.

Comment 5

[Jonathan Kew [:jfkthame]]

patch: http://hg.mozilla.org/mozilla-central/rev/004e7ca095fb
reftest: http://hg.mozilla.org/mozilla-central/rev/43a24a8896a3

Comment 6

[philippe (part-time)]

Thanks Jonathan, works fine now :-)
verified with a build @changeset b4e7f7d88a8c with the site in the URL field.