> > > �� Rendering is a non-reversible process
> >
> > True regardless of the engine.
>
> I would argue on this. With a small and different set of glyphs,
> especially when the script is known even the screen image could be
> converted back to Unicode. Of course, this would require more
> efforts, but this is not impossibly difficult like, say translating
> into a different language.
It seems that my previous reply to this list has been ignored: The
Adobe Glyph List (AGL) algorithm provides exactly this.
http://partners.adobe.com/asn/developer/typeforum/unicodegn.html
> By Glyph elements I mean the smallest components of a cluster. The
> process would look like converting Unicode to glyphs elements and
> positions, and for testing using these elements and positions
> converting them back into Unicode - they should convert back to the
> same or equivalent Unicode stream.
>
> Render: U+XXXX U+YYYY U+ZZZZ R-> G+MMMM G+NNNN
> Test: G+MMMM G+NNNN T-> U+XXXX U+YYYY U+ZZZZ or its equivalent.
With AGL, a glyph for the input characters U+XXXX U+YYYY U+ZZZZ would
be called
uniXXXXYYYYZZZZ
or, if more appropriate
uniXXXX_uniYYYY_uniZZZZ
> > > ��. Create a generic state machine thet can step through the
> > > input unicode characters, and spit out Glyph components and
> > > their relative hot spot positions.
> > > ��. Create states and a dynamically loadable state table per
> > > script per language system.
Have you ever looked at the Omega Project, a successor of TeX? It
uses finite-state machines (called Omega Translation Processes, OTP)
to do that. www.tug.org should give a link to the Omega Project.
> > > ��. Create bitmap and vector fonts. The glyph codepoints are
> > > defined in (��.) so this will be an easy process. Much easier
> > > than creating OpenType tables.
> >
> > Exactly equivalent to creating OpenType tables. You just make
> > fewer copies of the data (assuming availability of Free/Open
> > Source fonts).
>
> The difference is that the font creators would have all the Glyph
> components defined in a consistent way in our case.
Use glyph names compliant with the AGL.
> VOLT helps a lot when creating OT Fonts. But I fear it is still be
> possible to miss something and having one untested input combination
> rendered in an unexpected way. There are to many branches because
> of the exeptions, and because of the numerous features an OTF has.
Another tool to analyze OT fonts is Just van Rossum's `fonttools'
package which deassembles such fonts into XML-like tables.
http://fonttools.sf.net
Werner
��TL_"���|���'jYez���
܆+ކ�i����Y�)�Ɗ��X����
