Jungshik Shin wrote,
> > Actually, Mozilla doesn't do anything special for Latin combining > characters other than delegating the rendering to fonts/rendering > engines. Thereofre, when a font with OT table for combining > macron/overline is used (e.g. CODE2000), it renders them > correctly. If not (e.g. Arial MS Unicode), it renders them as spacing > characters. You may be interested to check out Mozilla bug 85373 > (http://bugzilla.mozilla.org/show_bug.cgi?id=85373). > Code2000 has only minimal tables for Latin OpenType pending system support from Microsoft needed for testing purposes. For glyph positioning, only 3 kerning pairs are included. For glyph substitution, only 10 discretionary ligatures plus several 'enclosed' glyph substitutions. Whatever is happening in Mozilla to improve the appearance of Latin text with combiners must be an innovation of the good folks at Mozilla. Lacking Latin OpenType support in Uniscribe, many "core" fonts available through Microsoft may well have chosen to use dotted circle glyphs as the default display glyphs while awaiting system support. This is probably a good approach, because fonts like Code2000, Cardo, et cetera, still have to rely on default glyph positioning in most products, which can result in undesirable overstriking. Where they don't overstrike, these combiners are as often as not poorly aligned. There's very little font developers can do to correct this without OpenType support being enabled for Latin script. Microsoft is working on adding Latin OpenType support to Uniscribe. Meanwhile, some browsers seem to be attempting to display, for example, the string "a" + "combining acute" as "aacute" if the glyph is available in the font as a precomposed glyph and the character is available in the Standard as a precomposed character. This is why some combiners may seem to work in certain cases, and not others. For instance, in Outlook Express on Windows 9x, the following alphabet + combining acutes is entered as the single letter followed by the combining acute mark. In the default font here, the expected result is that every single combining acute glyph would overstrike its corresponding base letter. This is because the default combining glyph position in this font is designed for lower case letters (with no ascenders) heights...: ĀB̄C̄D̄ĒF̄ḠH̄ĪJ̄K̄L̄M̄N̄ŌP̄Q̄R̄S̄T̄ŪV̄W̄X̄ȲZ̄ ...but, on this system, the capital letters A, E, G, I, O, and U are all getting a combining macron at the correct caps height. This is not happening based upon any instructions within the font. Rather, the system appears to be making these substitutions based on some system table, which in turn is based on TUS. (The rest of the capital letters look awful, they're being overstriked (overstricken?) by the combiners.) Anyway, hope this info is helpful. Best regards, James Kass.
