From: Martin Sevior (msevior@seviorpc.ph.unimelb.edu.au)
Date: Wed Oct 29 2003 - 00:51:47 EST
On Wed, 2003-10-29 at 00:54, danglassey-abi@ntlworld.com wrote:
> 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?
>
I'm *really* *really* wary of doing this. fl_BlockLayout has encoded
within it lots of accumulated wisdom.
Maybe we can reuse pango and/or parts or pango and/or pango
algorithims/modules in place of fb_LineBreaker and fp_Line::layout.
I haven't looked at what pango in detail. At the time of the last
"should we use pango?" discussion I wasn't as aware of the issues of
doing text layout as I am now. If Tomas is serious about doing this I
will take the time to investigate.
In any case I'd be happy to see the last of the stale pango code. Please
go ahead and remove it.
> > 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.
> >
Yes. This bothers me. But more than even this is the whole lot of
accumulated code that makes up the core of our application. The layout
code makes specific use of the capabilities of the graphics classes.
Maybe we could strip out the specific language shaping modules and use
them for our purposes.
> > (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).
>
No we can't do this. I'm struggling to come up with ideas that will
allow us to do bonobo embedding. I think we can do it by making external
applications a new type of image and re-using the fp_ImageRun code. Then
I can isolate the initial drawing of the embedded object to filling an
image which we can show in abiword.
To me the most useful features of pango are it's international line
breaking and glyph shaping code which requires detailed local knowledge
to get right. I hope we can extract this from pango or if not persuade
the pango developers to gives access to them via a decent API. Another
option would be to fork it and just extract the info we need. Of course
from then on it's up to us to fix bugs :-(
Martin
> 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 - 23:52:58 EST