On Mon, Dec 11, 2006 at 05:49:22PM +0100, Andries Brouwer wrote:
> On Mon, Dec 11, 2006 at 05:06:23PM +0100, Jan Willem Stumpel wrote:
>
> > I am beginning to think that the responsibility for correct
> > "combining accents" behaviour rests primarily with the rendering
> > engine, rather than with the fonts. The fonts must, of course,
> > include the combining accents, otherwise the accents will be
> > borrowed from other fonts; but I doubt that they really need
> > anchors or GPOS.
> >
> > E.g. say I am a rendering engine; I see a character which, from
> > its Unicode range, is either
> >
> > -- a "top" accent
> > -- a "bottom" accent
> > [-- a left accent if such things exist, a right accent, etc.,]
>
> In Hebrew, a dagesh is a dot centered in the glyph to double
> the consonant or change the pronunciation.
>
> The precise place where it should go must be indicated by the font.
> If one just centers a dot in the same area, it may well be
> (and in practice, in my Java experiments, is) invisible
> because it overlaps part of the glyph.
Then in principle you just need a 'center point' anchor for Hebrew
consonants. The point is that rendering combining marks should require
roughly O(nk) information (where n is the number of characters and k
is a small number of classes) as opposed to O(nm) or even O(nm^j)
(where m is the number of combining characters and j is the maximum
combining stack length).
Whether it's possible to support all combinations efficiently, I don't
know. The OpenType system is very poorly designed from what I can
tell. In the Tibetan fonts I've examined, rather than just saying
"character U+0F62 needs to use an alternate glyph when followed by any
of {list here} combining characters", there are individual ligature
combination tables for each pairing. Whether this is just lack of
understanding on the font designer's part or fundamental limitations
of OpenType, I'm not sure.
On the other hand, I've successfully implemented a O(nk) system with
UCF/uuterm, so I know it's possible. From what I've read, Apple's AAT
tables also sound like they're O(nk) and don't suffer from the
horrible "leave it to the rendering engine to decide what to do, and
decide incorrectly" syndrome of OpenType/Uniscribe/pango/etc.
Rich
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
