From: Daniel Glassey (danglassey-abi_at_ntlworld.com)
Date: Fri Nov 07 2003 - 16:04:21 EST
On Wed, 2003-10-29 at 05:51, Martin Sevior wrote:
> On Wed, 2003-10-29 at 00:54, danglassey-abi_at_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.
I'm really hoping that it isn't the case that fl_BlockLayout won't be
just thrown away. The question is whether or not it is necessary. Like
I've said in the other mail AW is still going to be doing a lot - the
larger scale layout since pango acts on paragraphs or less. Can that be
done with the current BlockLayout.
> Maybe we can reuse pango and/or parts or pango and/or pango
> algorithims/modules in place of fb_LineBreaker and fp_Line::layout.
Or just plain use them?
> 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.
I don't know about Tomas but I am serious. I'm aiming to get AbiWord to
be able to use silgraphite[1] . We are working to get pango to be able
to use it so it makes sense to get abi to use pango if it is possible.
Also, for win32 to do complex i18n layout properly you want to be using
uniscribe and that involves using the same break, itemize, shape and
render model as pango uses so the same issues are involved.
> 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.
But then we'd just have to maintain a separate copy and if new modules
come along then we'd need to keep track of that - yuck.
> > > (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.
um, I might have missed something but afaics those are the features of
pango. I haven't seen much more than that that it does (apart from
PangoLayout which is not the thing to use in AW[2]).
> I hope we can extract this from pango or if not persuade
> the pango developers to gives access to them via a decent API.
Define 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 :-(
Not a good idea. It'd probably be better to not do it than do that :(
> 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
[1] http://graphite.sil.org or http://silgraphite.sf.net
[2] http://www.abisource.com/mailinglists/abiword-dev/02/Apr/1066.html
This archive was generated by hypermail 2.1.4 : Fri Nov 07 2003 - 16:02:29 EST