At 04:11 PM 7/29/2003, Peter Kirk wrote:Well, I still think we are talking at cross purposes. I am not talking about storing this flag in the font but as a variable in the rendering process so that it how it renders the current glyph depends on a flag set when it rendered the previous one. To put it another way, the renderer is not a stateless machine.
Either I have not made myself clear or my understanding of the rendering process is even less than I thought. Perhaps I should have said "glyph" rather than "character". But the real point is that I am suggesting some kind of flag which could be preserved from outputting on glyph to outputting the next, on the lines of "the last glyph I output was a vowel" or "... a consonant" - with "vowel" or "consonant" defined simply as one of a particular list of glyphs or combinations. Is that possible, or is the rendering engine unable to preserve any kind of state from glyph to glyph?
It is possible to store information about a glyph for processing purposes. In OpenType this is done in the GDEF table, but the glyph types are currently limited to simple, ligature, mark and component. It is not essential to make such assignments much of the time; for example, you only need to classify a ligature as such if you want to position marks relative to different parts of the ligature (in which case you also define how many components the ligature has. The only GDEF classification currently necessary for Hebrew is 'mark'. If you wanted the GDEF table specification extended for, e.g. a distinction between consonants and vowels, you would need to approach MS and Adobe. I really don't recommend doing that at this stage, since this really is a problem that should be solveable at the text encoding level. The OpenType philosophy is very much opposed to handling anything that looks like a character processing issue in glyph space (unlike AAT and Graphite).
John Hudson
But I agree with you that this is a problem that should be solveable at the text encoding level. I would suggest this kind of solution only if the encoding level solution is rejected in response to arguments like "some people nowadays don't make this distinction and we don't want to confuse them, so this distinction which many people have made for 1000 years should not be encodable in Unicode".
-- Peter Kirk [EMAIL PROTECTED] http://web.onetel.net.uk/~peterkirk/
