Closed Bug 172771 Opened 22 years ago Closed 22 years ago

Xft crosses character encodings

Categories

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

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: dbaron, Assigned: blizzard)

References

Details

Attachments

(3 files)

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.
Attached file testcase (deleted) —
Blocks: xft_tracking
Summary: Xft crosses character sets → Xft crosses character encodings
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.
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.
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.
> 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.
Per Jungshik's comment, resolving INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago
Component: Layout → Layout: Fonts and Text
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: