xmlroff-list

[xmlroff] FO and Area Tree browser proposal

[Tony G. <Ton...@Su...>]

Posted here and on the xmlroff Wiki to see which one generates the
most responses.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

------------------------------------------------------------
FO and Area Tree Browser

The xmlroff design calls for an 'Area Tree Adjust' stage after the
initial formatting is done and before the area tree is written out as
PDF, etc.

The intent is to call loadable modules to do the work.

An idea for an initial loadable module that doesn't actually adjust
the area tree is to make a graphical browser that shows the FO and
area trees.

The browser would be:

*proof-of-concept for the loadable module technique
*useful visualisation tool for XSL
*useful debugging aid
*basis for eventual manual area-tree-tweaker

The current idea is a multi-pane or multi-window browser showing:

*FO tree
*Properties of currently selected FO
*Areas generated by currently selected FO
*Area tree with currently selected area highlighted
*Properties of currently selected area

In principle this could be extended to include panes or windows for:

*Formatted output with currently selected area highlighted
*Input XML document(s) with element or attribute that generated
currently selected FO highlighted

(All of which would really fuel the market for multi-head displays.)

GNOME or GTK+ would be the obvious choice for windowing toolkit, but
it could instead be done in Tk or any of a number of other
technologies.

Re: [xmlroff] FO and Area Tree browser proposal

[Charles B. <cbo...@hi...>]

I think this is an excellent idea especially your idea of seeing the
formated output in one pane and the FO and properties in another. I am
discovering that it is difficult to determine if a fo has been rendered
correctly; even a small fo has a lot of complexities. I also like the
idea of having loadable modules to work at different stages of
formatting. I can image not only being able to choose different output
formats but also having a choice different algorithms during the
adjustment phase.

I've never worked on a GUI application before and I image this one is
not too easy, but I'll bet it will pay off in the long run.

On Thu, 2003-03-06 at 07:00, Tony Graham wrote:
> Posted here and on the xmlroff Wiki to see which one generates the
> most responses.
> 
> Regards,
> 
> 
> Tony Graham
> ------------------------------------------------------------------------
> XML Technology Center - Dublin
> Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
> Hamilton House, East Point Business Park, Dublin 3            x(70)19708
> 
> ------------------------------------------------------------
> FO and Area Tree Browser
> 
> The xmlroff design calls for an 'Area Tree Adjust' stage after the
> initial formatting is done and before the area tree is written out as
> PDF, etc.
> 
> The intent is to call loadable modules to do the work.
> 
> An idea for an initial loadable module that doesn't actually adjust
> the area tree is to make a graphical browser that shows the FO and
> area trees.
> 
> The browser would be:
> 
> *proof-of-concept for the loadable module technique
> *useful visualisation tool for XSL
> *useful debugging aid
> *basis for eventual manual area-tree-tweaker
> 
> The current idea is a multi-pane or multi-window browser showing:
> 
> *FO tree
> *Properties of currently selected FO
> *Areas generated by currently selected FO
> *Area tree with currently selected area highlighted
> *Properties of currently selected area
> 
> In principle this could be extended to include panes or windows for:
> 
> *Formatted output with currently selected area highlighted
> *Input XML document(s) with element or attribute that generated
> currently selected FO highlighted
> 
> (All of which would really fuel the market for multi-head displays.)
> 
> GNOME or GTK+ would be the obvious choice for windowing toolkit, but
> it could instead be done in Tk or any of a number of other
> technologies.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> xmlroff-list mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlroff-list
-- 
Charles Bozeman <cbo...@hi...>

Re: [xmlroff] FO and Area Tree browser proposal

[Tony G. <Ton...@Su...>]

Charles Bozeman wrote at  6 Mar 2003 19:53:44 -0600:
 > I think this is an excellent idea especially your idea of seeing the
 > formated output in one pane and the FO and properties in another. I am

The formatted output is an eventual option.  I'm proposing to start
with just the trees, which will be simpler to implement.

 > discovering that it is difficult to determine if a fo has been rendered
 > correctly; even a small fo has a lot of complexities. I also like the
 > idea of having loadable modules to work at different stages of
 > formatting. I can image not only being able to choose different output
 > formats but also having a choice different algorithms during the
 > adjustment phase.

xmlroff currently doesn't do loadable modules.  It doesn't do loadable
modules for the output format simply because there's currently only
one supported output format.

My intention has always been to have loadable modules for the
adjustment phase to allow, as you say, a choice of different
algorithms during the adjustment phase.

 > I've never worked on a GUI application before and I image this one is
 > not too easy, but I'll bet it will pay off in the long run.

GTK+ (and GNOME) has a tree widget.  It seems to me that it would be
straightforward to walk the FO tree or the area tree and make a
corresponding GTK+ tree.  Having made the GTK+ tree from the FO or
area tree, it should be easy to get from a selected widget in the GTK+
tree to the corresponding FoFo or FoArea, and you can get from an FoFo
to its areas or from an FoArea to its FoFo easily enough.  After that,
it's "just" a matter of updating the appropriate windows and selecting
the appropriate widgets.

Presumably the GUI builders such as the Glade application will make
the GUI side easy to implement.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

P.S. Please don't include complete copies of previous messages when
     replying to an xmlroff-list post.  The SourceForge archive puts
     an entire thread on one HTML page, so the previous message is
     visible to anyone using the archive, and including it again just
     means people have to scroll past it to get to the following
     message.

Re: [xmlroff] FO and Area Tree browser proposal

[Dave M. <da...@da...>]

Please forgive my ignorance, but is there a standard DTD for the area tree 
stage?  That way you can just serialise the area tree as XML, and the 
graphical view can be an entirely separate app.  Might well make debugging 
easier.

Even without doing this, the browser should be a fairly simple job using 
GnomeCanvas.  Unfortunately I have a million-and-one other things to do at 
the moment... :-(

<blue-sky-musing>
I'm hoping to add custom previews to my app Conglomerate 
(www.conglomerate.org) that automatically update as you edit the XML DocBook 
source;  one possibility would be a FO area tree view showing the "live" 
results of XSL transformations...
</blue-sky-musing>

Dave Malcolm

On Thursday 06 March 2003 13:00, Tony Graham wrote:
> Posted here and on the xmlroff Wiki to see which one generates the
> most responses.
>
> Regards,
>
>
> Tony Graham
> ------------------------------------------------------------------------
> XML Technology Center - Dublin
> Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
> Hamilton House, East Point Business Park, Dublin 3            x(70)19708
>
> ------------------------------------------------------------
> FO and Area Tree Browser
>
> The xmlroff design calls for an 'Area Tree Adjust' stage after the
> initial formatting is done and before the area tree is written out as
> PDF, etc.
>
> The intent is to call loadable modules to do the work.
>
> An idea for an initial loadable module that doesn't actually adjust
> the area tree is to make a graphical browser that shows the FO and
> area trees.
>
> The browser would be:
>
> *proof-of-concept for the loadable module technique
> *useful visualisation tool for XSL
> *useful debugging aid
> *basis for eventual manual area-tree-tweaker
>
> The current idea is a multi-pane or multi-window browser showing:
>
> *FO tree
> *Properties of currently selected FO
> *Areas generated by currently selected FO
> *Area tree with currently selected area highlighted
> *Properties of currently selected area
>
> In principle this could be extended to include panes or windows for:
>
> *Formatted output with currently selected area highlighted
> *Input XML document(s) with element or attribute that generated
> currently selected FO highlighted
>
> (All of which would really fuel the market for multi-head displays.)
>
> GNOME or GTK+ would be the obvious choice for windowing toolkit, but
> it could instead be done in Tk or any of a number of other
> technologies.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> xmlroff-list mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlroff-list

Re: [xmlroff] FO and Area Tree browser proposal

[Tony G. <Ton...@Su...>]

Dave Malcolm wrote at  8 Mar 2003 16:44:48 +0000:
 > Please forgive my ignorance, but is there a standard DTD for the area tree 
 > stage?  That way you can just serialise the area tree as XML, and the 

There isn't a standard DTD for the area tree.

It isn't standardised by the XSL 1.0 Recommendation.  It was one of
the first things that came up for discussion when the EXSL-FO list
started up, but the discussion died after Ken Holman said that he knew
of a formatter that didn't produce an area tree.

Serialising either tree as XML would just require a simple variation
on the 'xmlroff -d2' or 'xmlroff -d4' output, which uses
fo_object_debug_dump().

 > graphical view can be an entirely separate app.  Might well make debugging 
 > easier.

Half the point of the browser idea is to prototype the loadable module
approach.  Writing it out as XML and using a separate app doesn't help
that part of the scenario.

Note also that the proposal is to be able to show both FO tree and
area tree views at once.

 > Even without doing this, the browser should be a fairly simple job using 
 > GnomeCanvas.

I had thought that a tree required GtkTree or similar, not a canvas
widget.  What am I missing?

 >               Unfortunately I have a million-and-one other things to do at 
 > the moment... :-(

Don't we all, and many of mine already have to do with xmlroff.

 > <blue-sky-musing>
 > I'm hoping to add custom previews to my app Conglomerate 
 > (www.conglomerate.org) that automatically update as you edit the XML DocBook 
 > source;  one possibility would be a FO area tree view showing the "live" 
 > results of XSL transformations...
 > </blue-sky-musing>

My blue-sky musing frequently concerns incremental updates: pushing a
small change, e.g. one changed word, in the source XML through the
XSLT transformation and through the XSL formatter without either
transforming the whole document again or reformatting the whole
document again.

Also, speaking as list administrator now, please only quote the parts
of the previous message to which you are directly replying or only
quote enough to establish the context.  Including entire copies of
previous messages reduces the signal-to-noise ratio in SourceForge's
one-thread-per-page mailing list archives.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

Re: [xmlroff] FO and Area Tree browser proposal

[Dave M. <da...@da...>]

On Saturday 08 March 2003 20:43, Tony Graham wrote:
>  > Even without doing this, the browser should be a fairly simple job using
>  > GnomeCanvas.
>
> I had thought that a tree required GtkTree or similar, not a canvas
> widget.  What am I missing?

I was thinking of using the canvas to render rectangular areas that can be 
clicked and dragged etc; nice for visual inspection of the results.  Mind 
you, a tree would be useful as well, for systematic "structural" browsing.  
(You probably want GtkTreeView for that; it's much better than the old GTK 
1.* widgets)

> My blue-sky musing frequently concerns incremental updates: pushing a
> small change, e.g. one changed word, in the source XML through the
> XSLT transformation and through the XSL formatter without either
> transforming the whole document again or reformatting the whole
> document again.

I wasn't aware this was possible...  and if you manage to do it I'll be very 
interested in finding out how :-)  I've (briefly) looked for "incremental" 
XSLT engines but couldn't find any.

>
> Also, speaking as list administrator now, please only quote the parts
> of the previous message to which you are directly replying or only
> quote enough to establish the context.  Including entire copies of
> previous messages reduces the signal-to-noise ratio in SourceForge's
> one-thread-per-page mailing list archives.

Oops... sorry.

Re: [xmlroff] FO and Area Tree browser proposal

[Tony G. <Ton...@Su...>]

Dave Malcolm wrote at  9 Mar 2003 13:29:23 +0000:
 > On Saturday 08 March 2003 20:43, Tony Graham wrote:
 > >  > Even without doing this, the browser should be a fairly simple job using
 > >  > GnomeCanvas.
 > >
 > > I had thought that a tree required GtkTree or similar, not a canvas
 > > widget.  What am I missing?
 > 
 > I was thinking of using the canvas to render rectangular areas that can be 
 > clicked and dragged etc; nice for visual inspection of the results.  Mind 

That would be simple to do (well, comparatively simple) if Pango's FT2
(or xft) backend could take the same PangoLayout as created by the
PDFlib backend.  Right now, I believe that the FT2 and xft backends
are too tied to 72dpi resolution.

 > you, a tree would be useful as well, for systematic "structural" browsing.  
 > (You probably want GtkTreeView for that; it's much better than the old GTK 
 > 1.* widgets)

Yes.  I installed GTK+ 2.2.0, and I've looked at the sample code in
gtk-demo.

 > > My blue-sky musing frequently concerns incremental updates: pushing a
 > > small change, e.g. one changed word, in the source XML through the
 > > XSLT transformation and through the XSL formatter without either
 > > transforming the whole document again or reformatting the whole
 > > document again.
 > 
 > I wasn't aware this was possible...  and if you manage to do it I'll be very 
 > interested in finding out how :-)  I've (briefly) looked for "incremental" 
 > XSLT engines but couldn't find any.

I haven't found any incremental XSLT engines either, but we are
speaking blue-sky, aren't we?

The first part of the story, alerting the XSLT engine to a change in
the source XML, could be done using something like DOM events [1].

The second part, going the incremental transformation, is left as an
exercise for the reader.

The third part, alerting the formatter, could also be based on DOM
events.

The fourth part, changing the formatted output, is not dissimilar from
what wil eventually have to be implemented for handling
page-number-citation and retrieve-marker and for handling the
area-tree adjustment phase.

So it's simple, really.

 > > Also, speaking as list administrator now, please only quote the parts
 > > of the previous message to which you are directly replying or only
 > > quote enough to establish the context.  Including entire copies of
 > > previous messages reduces the signal-to-noise ratio in SourceForge's
 > > one-thread-per-page mailing list archives.
 > 
 > Oops... sorry.

That's okay.  Some people's normal habits don't play well with
SourceForge's archive style, but you can't know that until you look in
the archives (or someone tells you).

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708


[1] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTypes-complete