From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Mon Mar 06 2006 - 11:24:16 CST
From: saqqara
> Windows XP/SP2. When I use COMBINING DOT BELOW with an OpenType
> font without specific support for the combination (e.g. current release of
> Times New Roman for most diacritic latin forms) the dot is placed to the
> bottom left of the character box rather than the centre (e.g. try d or D
> with the combining dot).
>
> Am I correct in categorising this as a Windows text rendering bug or am
> I missing a more subtle point about how Unicode software is expected
> to deal with this situation?
I don't think it is a bug. A limitation certainly, but it can be caused by several things.
And the first one is not the operating system, but the application that renders the text, and that is not able to use the OpenType tables that allow positioning the diacritics correctly.
The second reason is that the font selected to render this text does not contain the necessary glyph positioning tables or this table does not contain the specific letter+diacritic pair: many fonts do not contain the glyph positioning pairs for Latin letters with a dot below, so the application just tries to use the default relative positioning specified in the glyph for the separate diacritic.
Some smarter font formats allow specifying for each letter a small set of origin points for the attachment of diacritics, and then diacritics are positioned from this point instead of using the default position relative to the current position on the baseline. For this to work, each diacritic must specify which attachment point to select for its positioning.
This of course requires a smarter rendering engine, where there's not only 1 current position, but several current positions for different types of attachments (including the default position on the baseline).
This will work also to create stacks of multiple diacritics, if each diacritic can also override the attachment position of the next diacritics (but this will not work very well if diacritics are not stacked, such as in fully pointed Hebrew, because multiple diacritics aboce or below the letter are positioned horizontally and not stacked vertically, and so these multiple diacritics won't be centered correctly over or below the base letter; to work with such issues, it will benecessary to use glyph substitution tables to handle multiple diacritics as a group, prior to rendering this group relatively to the base letter; the group glyph will be rendered as a subroutine calling the two component glyphs positioned specifically and possibly narrowed).
For this algorithm to work, the renderer must however support the glyph reordering algorithm; in Windows this is what Uniscribe provides, so applications that don't use Uniscribe (or that don't use rendering components that support Uniscribe) may not be able to order the multiple diacritics prior to positioning them. Without it, the applications however should at least support the normalization of input strings before rendering them (it will solve most positioning problems).
This archive was generated by hypermail 2.1.5 : Mon Mar 06 2006 - 12:57:37 CST