From: danglassey-abi@ntlworld.com
Date: Tue Oct 28 2003 - 08:54:54 EST
On 28 Oct 2003 at 8:39, Tomas Frydrych sent forth the message:
Thanks Tomas.
> > sounds like a good idea. Have you got an idea of the shape of the
> > rewrite that is required?
>
> To make sensible use of Pango we would basically need to throw away
> the present fl_BlockLayout and use Pango to do the block layout for
> us -- in essence we are talking about writing much of the code in
> text/fmt from scratch.
Martin and the other layout gurus, would this be the case?
> There are two questions that the need to be considered before this is
> attempted:
>
> (1) Does Pango have sufficient capabilities to replace the present
> block layout engine? For instance, how do we represent internally,
> and go about drawing, things like superscripts, hyperlinks,
> spellchecker squiggles, etc.
Squiggles are in the pango todolist as an extension to the PangoUnderline text attribute. So it ought to be possible to do that. I don't know about the others.
>The editing window of a wordprocessor
> makes much greater demands than does a basic widget set, and when I
> originally started working on it, the Pango API was much more
> suitable for a widget set then a wordprocessor.
>
> (2) How portable is Pango? Because of the substantial rewrite of the
> text/fmt classes, it is almost certain there would have to be related
> changes elsewhere in AW: I think it only makes sense to do this, if
> it can be done in XP land (the idea that much for the code in
> text/fmt would move out of the XP land is terrifying on its own).
Some things have to be out of XP land, the question is whether they can move to gr_NativeGraphics or there has to be a native layout manager class. (see below for why I think why)
> My
>experience 18 months (ago) was that Pango is really a *nix library.
>
> One of the problems I run into was lack of adequate XP API. Pango has
> several platform-specific shaping engines (X, win32 and FT2),
> offerring significantly varying capabilities (only the X engine was
> feature-full), but more importantly, the XP API did not provide
> sufficiently low-level access to the engine. For many of the things I
> needed to do in our XP code, I would have to use X/FT/Win32-specific
> calls.
What kind of things?
> Then there is the larger question of being able to use Pango on
> QNX/BeOS/Mac. The FT2 engine would make that possible in theory, but
> then someone needs to port FT2 to QNX/BeOS/Mac;
I'd be suprised if it doesn't already work on all those. However, imho the ft2 engine is not the right solution. Pango for win32 uses the native shaping system (uniscribe) where it deems it necessary.
For complex i18n text layout it would make sense to use the native systems. On MacOSX that means ATSUI, on Win32 that means uniscribe (or pango->uniscribe), on Gtk/Gnome that means pango, don't know about QNX or BeOS.
Does it seem feasible to make a layout class that would provide the breaking and other funcs that the rest of AW layout requires? Since pango only works on a paragraph at a time AW still has to do a lot around it.
What kind of things would this class need to provide?
> then there is the glib dependency. It seems that we are set to use
> glib anyway, but I have the feeling the portability question has not
> really been thought through.
It's being thought through.
Regards,
Daniel
-----------------------------------------
Email provided by http://www.ntlhome.com/
This archive was generated by hypermail 2.1.4 : Tue Oct 28 2003 - 08:56:14 EST