From: Martin Sevior (msevior@physics.unimelb.edu.au)
Date: Wed Jul 09 2003 - 19:09:06 EDT
On 9 Jul 2003, Luca Padovani wrote:
> Hi Martin,
>
> On Wed, 2003-07-09 at 11:20, Martin Sevior wrote:
> > ggv is a good example to work from. eog is another good example. I can
> > tell you where to look in the abiword source tree for how we it in
> > AbiWord.
>
> yes, that would be very useful. So you're implicitly saying that AbiWord
> can act as both a container and containee (w.r.t. bonobo architecture).
>
Unfortunately no. We only act as a container right now. ie AbiWord can be
embedded in other apps. I don't think it will be too hard to have AbiWord
act as a containee but we have not worked a generic file format and
structure for compound documents yet. We plan to do this in
collaboration with the Gnumeric team who have some experience with this
and the pitfalls that need to be watched out for.
That said it is a post 2.0 todo item. The 2.0 release is (currently!)
about 3 - 4 weeks away so we should be in the position to start
implementing relatively soon. Maybe we need to try a few things quickly
and see where they go wrong before settling on a final structure.
> > You will need to move to gtk2 for a start. I think it would also be a
> > good idea to move to using fontconfig to find fonts and xft2 to draw on
> > screen.
>
> Well, it hasn't been released yet, but there already is a port of
> gtkmathview to GTK2. To be honest, the port is partial. My first plan
> was to switch to pango rendering completely, but math fonts have their
> own encoding and glyphs, so that a custom mapping Unicode->glyph index
> has to be implemented anyway. Right now the GTK2 port still uses some
> deprecated APIs to render glyphs on the drawing area. What you're saying
> here is that I should implement a rendering system based on Xft2
> directly, which should be more or less trivial as you pointed out. At
> the same time, I'm not sure how fontconfig can be of any help...
>
fontconfig is useful for finding all the scalable fonts on your system. If
a user doesn't have a math font present you can direct them to a website,
download it and bingo, fontconfig will find it and configure your app to
use it. It's just a lovely utility.
> > The issues with using bonobo to render into abiword however are a lot
> > more complex than simply drawing into a rectangular area in gtk widget.
> > (Which is what AbiWord-2.0 and ggv do)
>
> I agree
>
> > Thinking about this some more, it occurred to me that we would
> > probabally like much closer integration of GTKMathView with abiword than
> > just using it as a bonobo component.
>
> this is certainly the long-term goal. I wonder if you ruled out the
> possibility of using a rich, math-dedicated bonobo interface for this
> just because of performance reasons or if there's some other issue
> behind.
Well one reason is that I can't see bonobo running on win32 anytime soon.
Another is that Gnumeric have reported terrible problems trying to make a
bonobo-ised charting system work. They have now abandend bonobo for their
own charting library running in their own address space.
Another reason is performance. Even in MS Word there is a noticable delay
between when text and maths appear on the screen in the same document if
you scroll it from off screen to on-screen.
Another is that I think the best user interface for creating and editing
maths would have the equation right in the document and to just move a
blinking caret through the maths just as you would regular text. It seems
much easier to do this within our own address space.
Finally it has been my experience that debugging remotely executing
applications is very difficult. I have learnt some tricks to help with
this but it is still a pain and much harder than working in your own
address space.
> I've noticed that both ggv and eog implement their own
> specialized interface. Math is rather more complicated than a
> rectangular image, but finding a good common communication protocol for
> formatting components is also a very interesting subject by itself.
>
Of course you're right here. It may be that most of the issues I've listed
above could be overcome with the right interface. It *IS* useful to be
able to wrap all the complexities of correct maths layout into a module
with well defined interfaces with clear seperation of AbiWord and
GtkMathView scope's of operation. Nor would the work be wasted if it were
decided to move inside the AbiWord address space.
> > Then we could use AbiWord's own layout engine to tell where to split
> > equations over multiple lines and line-up equations above equal signs
> > etc.
>
> breaking math formulae is a very delicate task. In an early version of
> gtkmathview there was support for automatic line-breaking of formulae,
> but it turned out to be not really effective and too naive. As breaking
> a formula implies knowing at least some of its semantics, I think that
> the responsibility for finding breakpoints should be within gtkmathview,
> given the space constraints that are communicated from AbiWord.
>
OK we can work this way. AbiWord's layout engine places and text and other
objects into "fp_Run" classes. These have numerous subclasses, some of
which can be split, some which can't. Text runs can be split and in fact
the layout engine requests a split position from the runs, the runs
respond by telling the layout engine where they can split and then the
layout code splits the runs and deals with the result.
I think we can re-use much of this with maths and equations. The difficult
part will be extending it to deal with aligning equations one above
another and for multi-line equations. However we can work out how to deal
with multi-line equations later.
In any case I'm all for trying new ideas.
> > might also be a
good way to get something quickly running in AbiWord
> > before we've worked out how to do solve the integration issues.
>
> this is exactly my plan.
>
Great!
> > OK, well as I said I'm very happy to help and the first step is
> > definately a port to gtk-2.
>
> I'll try to write an Xft2 backend for gtkmathview if this is what we
> need to start. In the meantime, my student is investigating the bonobo
> architecture.
>
OK. See src/wp/ap/unix/ap_UnixApp.cpp for how we do bonobo embedding.
See src/af/gr/unix/gr_UnixGraphics.cpp for how we use XFT2.
> Hope to see some running code very soon.
>
Me too! I have some simple code for a test-container for your bonobo
control that you might want to look at.
Cheers
Martin
> Cheers,
> -- luca
>
>
>
This archive was generated by hypermail 2.1.4 : Wed Jul 09 2003 - 19:21:48 EDT