Talk:Dynamic Layout Support Discussion

Discussion on XSL-FO

That sounds very good. When reading your text, I must think of XSL FO, the XSL Formatting Objects. For a good example of an implementation of XSl FO, take a look at the Apache FOP (http://xmlgraphics.apache.org/fop/).

I build some stylesheets for XSL Fo which can be used for several types of texts, perhaps it could be an example for you (which is not sooo big and complicated as docbook): http://www.thomas-zastrow.de/st/

Thanks for the references. I'm not too familiar with XSL-FO, so I'll take a look at them. But here are some of my current thoughts on the issue, and why I'm not sure FO is the ideal match to an interactive dynamic layout process (though it could certainly still be used in its own right of course!). I think they may be somewhat separate layout approaches, though it could be possible to adapt current FO-based stylesheets to take advantage of a WSYSIWYG approach such as I'm suggesting.
-------

From what I understand currently, an XSL-FO file could be treated as input content like any other XML file and used with my proposal if suitable import filters were written (by me or anyone else, or an alternative import mechanism found using an external parser). If desired, an arbitrary XSLT stylesheet could probably be applied (by an external XSLT processor) to a source XML file to create the XSL-FO dynamically as well before importing by Scribus--it would be easy enough to call an external processor as a filter.

However, if I understand correctly, a FOP is a completely different story, as it is designed to do all of the layout work from the FO input itself and generate a final output format like PDF. This leaves no editable content to import and manipulate within Scribus, which is the whole idea of my proposal. A FOP-generated document thus would not use Scribus at all for its design or layout, and would better be linked to as an image (the TeX-frame project is taking that approach, and it seems may now support arbitrary external programs to generate the content, not just TeX.)

Thus, as I said above, to actually be able to edit XSL-FO-imported content in Scribus, the FOP essentially must be replaced by some method to get the FO content into and rendered as native Scribus objects, which my project could manipulate in a structured fashion.

A final consideration is that FO, as I understand it, is intended as a processed intermediate form of a document, usually generated from a source file with more semantic information about the content. While there is no reason an FO file could not be processed using my framework given the needed import filters, the strength of my proposal is in its ability to manipulate and dynamically reformat semantic content within Scribus using a GUI interface and layout styles.

Thus the ideal way to use a <source file> -> XSL-FO stylesheet (an XSLT filter) would be to import the stylesheet itself as a layout style and let Scribus directly import the source XML file. It might be doable, but it would take some work, and it might be easier to just create the styles and filters directly in Scribus.

This discussion has gotten a bit long, but to summarize:

• XSL-FO could be imported the same as any other XML file, with suitable filters
• An FOP does all the formatting of the FO document itself, and hence bypasses any possible editing in Scribus--they're two separate layout paths
• An XSL-FO document has already lost semantic information from the source document, so a more complete editing experience in Scribus, taking full advantage of my proposed interactive layout system, would import the source file directly rather than the FO form. However, an XSLT stylesheet designed to create FO output could be converted to, or used as the basis for, a Scribus layout style as per my proposal

I hope that clarifies the relationship between a fully automated layout path like XML->FO->FOP and my proposal for interactively-controlled, WYSIWYG structured layout editing, as I see it. Please add any comments or correct me if I've misunderstood something. :) --Mkoren 06:41, 13 April 2007 (CEST)

Agreement

I agree with you that the XSL FO functionality is better done within the LateX extension.

Which works out well since that's the project actually being done this summer. :) I did look through the list of FO objects and properties on the Apache site though, and they look fairly interesting, including some relative positioning functionality. It could certainly be interesting eventually to come up with some kind of mapping between FO and Scribus objects, and the relative positioning aspects could in fact make use of my approach. That would let Scribus behave as the FOP in this case.

And if something like your stylesheets could be imported as a selector/transformation filter for source content (I didn't get into that too much yet in my proposal, but I have it in mind) and FO export were also possible, then Scribus could serve as a kind of GUI editor for stylesheets for this kind of workflow. So the match might actually work in the long term. :) --Mkoren 02:23, 14 April 2007 (CEST)