From: msevior_at_physics.unimelb.edu.au
Date: Thu Feb 19 2004 - 08:18:54 EST
>
> This is the beginning of major refactoring of the bidi processing and
> glyph shaping, which has two objectives:
>
> 1. To provide transparent abstract interface between our layout
> classes and a shaping engine; this will allow us to link in an
> external shaping library, be it Pango, Uniscribe or SIL
> Graphite, or to load it as a plugin.
>
> 2. To make the bidi processing conform fully to the Unicode bidi
> algorithm. This will require to move some code from fp_Line into
> fl_BlockLayout.
>
> The present commit goes someway toward #1. The GR_Graphics class has
> now a number of new virtual methods, of those the most significant are
> itemize(), shape() and renderChars(); there are some new classes to
> allow passing of data between these methods without having to
> worry about implementation details.
>
> I have also added a new class GR_GraphicsFactory() which will allow us
> to have parallel graphics implementations, both built-in and as
> plugins. For example, on win32 we could have graphics that uses
> Uniscribe, a default one that offers no complex script support and
> another one that uses SIL Graphite; the user will be able to choose
> which to use (or a plugin will replace the default implentation with
> its own as it loads). The factory will be accessed via XAP_App, but
> some work is still required before it will be usable.
>
> The UT_contextGlyph class underwent change of identity; it is now
> called GR_ContextGlyph and lives in the corresponding place. I have
> modified the makefiles, but not the MSVC project files.
>
> This is work in progress; there is still quite a bit of code in
> fp_TextRun that makes assumptions about implementation of the shaping
> engine and which needs to go. Mostly it is a question of moving it into
> some other suitable place.
>
Hi Tomas,
This seems to be exactly what we need to be able to re-use all
the hard work done by others. Good Luck and let me know if I can
help.
Cheers
Martin
> There is very little of new code, so things should work just as they
> used to, if not, I will endeavour to fix things promptly.
>
> Tomas
This archive was generated by hypermail 2.1.4 : Thu Feb 19 2004 - 08:23:36 EST