172771 - Xft crosses character encodings

Status: RESOLVED INVALID

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I've found testcases where Xft is crossing character sets.  See bug 126919
comment  235 and bug 126919 comment 239 (search for mWesternFont, although I'm
not sure if that's actually the problem).

Unfortunately, this is somewhat difficult to reproduce -- it requires having a
font installed that's *not* available with iso-8859-1 encoding, and it may
require that it's in a similar (1-byte?) encoding, depending on what the
underlying problem actually is.

In any case, I'll attach the testcase that demonstrates the bug on my system. 
It won't work on systems without such a font, though.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot of attachment 101823, showing bug

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot of attachment 101823, showing correct behavior

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I did try and debug this a week or so ago, and my memory (which may be a little
fuzzy) is that we were going through the 16-bit codepath and everything looked
right.  So (since blizzard cc:ed Keith on another bug), I'll cc: him here as
well, since I'm worried this might be an Xft bug.

Comment 5

[keithp]

Can you send me a pointer to the font causing the problem?  Fontconfig unifies
the unicode, apple roman and adobe symbol tables present in the font to produce
the final mapping as I've found many fonts with ascii glyphs encoded only in the
pple roman table and not the unicode table.  This may cause mismapped entries
for fonts which have a bogus apple roman table.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The font is one of the fonts that comes with Windows.  If you have a Windows
machine (at least with more recent versions), you can get in the International
(?) Control Panel, by getting the Middle Eastern fonts at the bottom of the
first tab in the panel.

Comment 7

[Jungshik Shin]

> This may cause mismapped entries for fonts which have a bogus apple roman table.

As you expected, the font  I guess David used(one of david*.ttf that come with
Windows) has 
a bogus Apple Roman cmap. A part of the output gen. by my test program is shown
below:

Apple Roman cmap: 
        code=U+0000C0  gidx=0x0000cf
        code=U+0000C1  gidx=0x0000b9
        code=U+0000C6  gidx=0x000092
  
Unicode cmap:
         code=U+00E804  gidx=0x0000cf
         code=U+0005F4  gidx=0x0000b9
         code=U+0005BC  gidx=0x000092

   Below is  a part of APPLE Hebrew encoding table:

0xC0    0xF86A+0x05DC+0x05B9    # Hebrew ligature lamed holam     
0xC1    <RL>+0x201E     # DOUBLE LOW-9 QUOTATION MARK, right-left ==> U+05F4
0xC6    0x05BC  # HEBREW POINT DAGESH OR MAPIQ

Comparing all threes, you can see what's going on, can't you? 

What claims to be APPLE ROMAN cmap in the font is actually  'Apple Hebrew'
cmap. Perhaps the guard against fonts like this is for fontconfig to give a higher
priority to Unicode cmap than Apple Roman cmap. 

Anyway, I think this is not a Mozilla bug. 

Comment 8

[Christopher Hoess (gone)]

Per Jungshik's comment, resolving INVALID.