565766 - RTL text garbled for font-family:Verdana,Arial,sans-serif; on OSX 10.5

Status: NEW

(Core :: Graphics, defect)

Description

[Axel Hecht [:Pike]]

Attachment: test case with the same text with and without font-family

I'm seeing funny garbled text for RTL text that's styled with 

font-family:Verdana,Arial,sans-serif;

This seems to be a recent regression on central, and probably bound to 10.5.

Comment 1

[Axel Hecht [:Pike]]

Attachment: screenshot of what it looks like

Comment 2

[John Daggett (:jtd)]

WFM with trunk build on 10.6.  Suspect this many be releated to a specific font.

Comment 3

[John Daggett (:jtd)]

Guessing this might be related to using the MS cmap that I'm just guessing here.

Axel, using FontBook could you note the version of Arial and where it's located?  Select Arial Regular, then Preview > Show Font Info.

Comment 4

[Axel Hecht [:Pike]]

Johnathan can reproduce on a vanilla 10.5.8, per irc.

And the culprit is apparently the installed Arial mess.

Further local testing confirms that Verdana isn't found at all, and sans-serif is fine, as is Arial Hebrew.

Comment 5

[Jonathan Kew [:jfkthame]]

I think this was triggered by the landing of bug 554820.

However, I'm not entirely sure what's happening yet, and suspect that it may actually indicate an underlying flaw in our cmap-handling and font-matching behavior.

Comment 7

[Jonathan Kew [:jfkthame]]

The problem arises because on 10.5, Apple Type Services is returning a synthetic cmap table for Arial rather than the original cmap from the font, and the Unicode-platform subtable gets customized to modify the apparent character repertoire (hiding the Hebrew characters, I suspect, although I haven't fully disassembled it to check yet).

The patch in bug 554820 causes us to look at the Microsoft-platform subtable instead, which ATS doesn't munge; but then this leads to a mismatch when Core Text uses the modified table, decides the font doesn't support the characters, and does an internal fallback to some other font with incompatible glyph IDs.

I'm planning to back out bug 554820 as this is obviously an unacceptable mess, and will look into more refined approaches to solving that issue. Also wondering if we can reftest some of these things, though it'll be tricky as the behavior is OS-, version- and font-dependent .... and once we introduce harfbuzz, it'll be dependent on the renderer preference, too, as HB will not suffer from this confusion.