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)
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]
Comment 2•22 years ago
|
||
Does the interfering font have proper Unicode character to glyph mappings in it?
Old Cyrillic fons usually don't have those.
Comment 3•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
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.
Comment 5•22 years ago
|
||
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?
Comment 6•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
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.
Comment 9•22 years ago
|
||
The result after removing ER Bukinist KOI8. Mozilla finds and uses TITUS
CyberBit Basic, although with some serious typographical issues.
Comment 10•22 years ago
|
||
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.
Comment 11•22 years ago
|
||
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.
Reporter | ||
Comment 12•22 years ago
|
||
Marking confirmed per comment 8.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 13•15 years ago
|
||
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.
Description
•