This is a very interesting and ambitious project. I would like to see
such a project succeed. But WYSIWYG editing is very hard to
achieve. That was (and is) the case with TeX, where it was tried, and
it is the case with FOP. As Jeremias already answered, FOP is not
close to such a goal. We would need a whole lot more developers than
we have now, and before that, a good design for this goal.

In principle it should be possible to let FOP know which subtree of
the FO file has changed, and one could let FOP update that part of the
FO tree in memory. It is harder to determine which part of the layout
has changed. In addition, FOP has a total fit approach to layout,
which is not friendly to a partial update. Currently FOP tries to
dispose of elements in memory as soon as possible, in the interest of
minimal resource usage. A WYSIWYG approach would require that FOP
keeps FO tree, layout elements and perhaps a number of finished pages
in memory.

Do I remember correctly that EuroMath is developed in Academia? FOP
could use a similar sponsorship. Without it, this is far too ambitious
for us.

Regards, Simon

On Mon, Sep 25, 2006 at 09:08:40AM +0200, Jeremias Maerki wrote:
> On 23.09.2006 23:12:06 TomᚠStudva wrote:
> > Hi developers,
> > 
> > We are using FOP as rendering engine for FO in wysiwyg xml editor
> > When opening about 40 page fo
> > document, the editation is ugly slow. We can track changes in source
> > document(also in case using XSLT), but  there is a principal error, because
> > we don't know how to update the FOP produced trees, so new FOP is created to
> > layout document after change and further render by Draw2d (we implemented
> > some basic renderer composed of Draw2D Figures, which are organized into
> > tree). 
> > 
> > I' ve also profiled our application on such big document, from typing to
> > update of screen and found out, than FOP consumes 1/3 of processor time,
> > that is too much if we optimize anything but not FOP- it takes on good PC
> > about 10 seconds, so FOP 10/3 = 3sec. 
> > 
> >  
> > 
> > So, is there possibility to update the FOP produced trees according to
> > change in XML (to use it in editor manner, not only rendering engine)?
> No, FOP has not been designed to be used as a backend of a WYSIWYG
> editor like EuroMath2. That's a new requirement/wish. We'd have to find
> out if and how FOP can be changed to fulfill it. At any rate it's an
> expansion of the project scope which could be subject to a project
> decision depending on how extensive the necessary changes can become.
> > Or if not, is there possibility to recycle FOP PageSequence which haven't
> > changed?
> Not at the moment, maybe with some hacking. It's not just the
> page-sequence that would have to be recycled. You'd have to find ways to
> keep the unchanged page-sequences in memory and that includes not only
> the FO tree but also the area tree. However, changing a page-sequence in
> the middle might invalidate later page-sequences.
> > And last, is there option to speed up FOP generally, by lowering output
> > quality or something?
> Not by lowering the output quality, no. You can help by profiling and
> optimizing FOP and you can make sure the editor only generates the
> minimal FO content to produce the right document. Many editor generate
> much too much (redundant) content not making use of property inheritance.
> That can have an influence on performance.
> You're welcome to help us improve FOP to better match the requirements
> of EuroMath2. I'm pretty sure we currently don't have the resources to
> help you much in this direction. We can give you pointers and we can
> help you figure out what needs to be changed.
> Please note this is my take on the situation and may not reflect the
> opinion of the whole community.
> I didn't know of EuroMath2 before your post. If I interpret this
> correctly it is a content editor rather than an editor to create XSLT
> stylesheets.
> I've also taken a peek into your wishlist. I don't think you can
> currently find any open source FO implementation that is better suited
> for EuroMath2. Concerning the "partial FO rendering possibility": It
> might be possible to come up with a way to render, say, only a single
> fo:block-container with relatively little effort. This might have the
> possibly interesting side-effect that we could write a plug-in for Batik
> to render FO content within an SVG. :-)
> Jeremias Maerki

Simon Pepping
home page:

Reply via email to