Closed Bug 164488 Opened 22 years ago Closed 15 years ago

"ER Bukinist KOI8" font interferes with Mozilla's display of other Unicode Cyrillic font text

Categories

(Core :: Internationalization, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugmail, Assigned: tetsuroy)

References

()

Details

(Keywords: intl)

Attachments

(4 files)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020818 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020818 When the "ER Bukinist KOI8" font and another font containing Cyrillic characters such as TITUS Cyberbit Basic are installed, a page explicitly specifying the use of the latter font via CSS will fail to display Cyrillic characters in that fon Reproducible: Always Steps to Reproduce: 1. Install the attached ER Bukinist KOI8 and TITUS Cyberbit Basic fonts 2. Access the URL Actual Results: The Cyrillic characters are not displayed in the specified TITUS Cyberbit Basic face. Expected Results: The Cyrillic characters should have been displayed in the specified TITUS Cyberbit Basic face. Uninstalling the ER Bukinist KOI8 font restores functionality.
Okay, fonts are too big to attach here, and I probably shouldn't redistribute them, anyway. You can download them from the following URLs. ER Bukinist KOI8: [http://babel.uoregon.edu/yamada/fonts/russian.html] TITUS Cyberbit Basic: [http://titus.fkidg1.uni-frankfurt.de/unicode/tituut.asp]
Does the interfering font have proper Unicode character to glyph mappings in it? Old Cyrillic fons usually don't have those.
Re comment 2: shouldn't matter, since the test case in bug 111728 (http://bugzilla.mozilla.org/attachment.cgi?id=95824&action=view) is given in native UTF-8. If those cyrillic glyphs are not Unicode (they are in KOI8-R if I understand this right), or if they have the wrong mapping, the correct glyphs from Cyberbit should be rendered. Also, Mozilla should render with the font specified in the style sheet (Cyberbit). Period. Since it doesn't, this is in fact still a dupe of bug 111728, IMNSHO. It shouldn't matter a bit what other fonts (or language kits in the Classic partition) are installed.
No, no. The mapping tables matter a lot. Mozilla's Mac GFX knows nothing about KOI. The KOI page is converted to Unicode when Mozilla reads it then Mozilla asks ATSUI to render the Unicode characters. ATSUI can't do its work properly if there are fonts that don't have proper data about the correspondence of Unicode code points and glyphs. In the era before Unicode there were a lot of seemingly Cyrillic or Greek fonts that don't advertise their contents in an ATSUI-compatible way. You don't want to have those around on OS X (or on Windows 2000/XP for that matter). It is not Mozilla's job to work around obsolete or broken fonts, so before going further, it would be important to verify how ATSUI sees the character-glyph correspondence of the font.
ATSUI seems to barf at it. Copying the example http://bugzilla.mozilla.org/attachment.cgi?id=95824&action=view and pasting into TextEdit, it is rendered with Lucida Grande and Warnock Pro (yat). Trying to change to ER Bukinist KOI8 results in the first two letters being rendered in Hiragino Kaku Gothic Pro and the rest using Warnock Pro. This is the typical TextEdit barf. Using Unicode Font Info, it seems to be encoded in "Cyrillic (MacOS)", with 226 glyphs. The Cyrillic glyphs lie in the ISO 8859-1 Latin-1 supplement, and are thus not real Unicode Cyrillic glyphs. The rest of the glyphs lie in the Basic ASCII section. http://koi8.pp.ru/ has real KOI8-R chars, and these cannot be rendered in TextEdit with ER Bukinist KOI8. Mozilla supports KOI8, so therefore there should already exist an encoding converter. Thus, it is somewhat illogical that Mozilla tries to render characters in the Cyrillic section of Unicode with some glyphs in the Latin-1 section... how can it do this trick without consulting the legacy MacOS encoders?
This shows that the "cyrillic" chars are actually in Latin-1. Rendered with TextEdit, and thus it doesn't do anything special when encountering false chars. It is considered a Latin-1 font by ATSUI.
I think the point is that having this font installed should not break other fonts. A page that explicitly specifies using one font should not fail simply because some other font is installed, which is the case here.
Attached image Confirmation
Confirming with Mozilla 2002-08-22-11. The existence of ER Bukinist KOI8 in ~/Library/Fonts will make the font display faulty at the given URL.
Attached image (Semi-)normal behavior
The result after removing ER Bukinist KOI8. Mozilla finds and uses TITUS CyberBit Basic, although with some serious typographical issues.
Further investigation yields that one can replace the "TITUS Cyberbit Basic" definition in the style sheet with "Code2000", "Arial Unicode MS", "Cardo" and "Warnock Pro", with the same result: it just displays question marks, although all of the mentioned fonts are well capable of displaying the test.
Keywords: intl
QA Contact: ruixu → ylong
Omniweb handles this as expected, with excellent ATSUI rendering. This is with ER Bukinist KOI8 installed. One could expect that Chimera did the same, but it is actually regressing to some Carbon behavior often seen with iCab and Explorer. Without Bukinist KOI8 installed, something weird happens in Chimera. The yat is now correctly rendered, but the other cyrillic chars are rendered in a sans-serif font... IE is complaining about XML well-formedness, but it is not really important how IE renders this. It has its own limitations in that area.
Marking confirmed per comment 8.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: amyy → i18n
Flags: blocking1.9.0.17?
Flags: blocking1.9.0.16?
This is WORKSFORME in 1.9.0.x onwards
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: blocking1.9.0.17?
Flags: blocking1.9.0.16?
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: