On 08/05/2002 10:20:31 PM "Carl W. Brown" wrote:
>Fujitsu implemented it in the font rendering engine.
But they were not dealing with complex-script support. That makes a huge
difference. If there were not any glyph transformations between the cmap
lookup and rasterisation, your idea indeed would not require major changes
to the system. But we must assume a glyph transformation engine that lies
between those two points.
> Many fonts such as
>TrueType are encoded in Unicode even if the text is in code page. Thus
Euro
>would always be x'0020AC' even if you are running a Widows code page
with the
>Euro mod.
Yes, but if the software is using an old codepage, e.g. the original
codepage 1252, then 0x80 will be getting mapped in the codepage to U+0080,
and that is what will be retrieved from the font. My point still stands.
>Using glyph positioning you can with the worst variation limit the
number of
>glyphs to 87.
OK, this is an interesting idea that could work: at cmap-lookup time, the
layout engine identifies characters that are not supported in the cmap and
instead inserts a sequence of four or six glyphs (or perhaps more with
your trick for indicating planes -- I don't recall the details) while also
setting whatever features are needed to get GPOS lookups (or equivalent in
systems other than OpenType) to happen.
Why 87 glyphs? I.e. why so many? Couldn't it be done with 16 plus what you
need for indicating planes?
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <peter_constable@sil.org>
This archive was generated by hypermail 2.1.2 : Tue Aug 06 2002 - 06:55:35 EDT