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.
This archive was generated by hypermail 2.1.2 : Mon Aug 12 2002 - 19:56:31 EDT