Mark Davis wrote:
> The Unicode Standard does define the rendering of such combinations, which
> is in the absence of any other information to stack outwards.
> A dumb implementation would simply move
> the accent outwards if there was in the same position. This will not
> necessarily produce an optimal positioning, but should be readable.
Note that it also should increase the line spacing.
Note also that the renderer should notice that event, even in when there
is interleaved unrelevant (zero-width) characters.
And we are using a dumb implementation.
Anyway, my point was not about this, which are as you say, the basics of
the dumbest renderer.
No, I was thinking about the implications of mixing Nagari consonants
with kana diacritics (or the contrary); or circling (U+20DD) around
Indian conjuncts, or else around superscript digits; or the Tibetan
subjoined below Latin letters (how do they attach?); or Jamos followed
by a virama or a Telugu length mark. Etc.
My point was it is *not* a good idea to render an out-of-context
Telugu length mark (U+0C55), when it follows for example a Latin vowel,
as a macron, even if this is the "logical" behaviour. Such code will be,
IMHO, just waste.
> If it take megabytes of code to do [that] there is probably something
> else wrong.
I do not count a dumb implementation as "decent".
And yes, I was overemphasing with "megabytes". The OT support in FreeType,
which does only a small part of this task, is only 315 Kbytes of C code.
So I expect the not-so-dumb renderer based on it, to be around 0.5 megabyte.
Which does not take in account the code embeeded in the OT fonts themselves.
As a result, yes, please remove the "s".
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:15 EDT