Mailing-List: contact fop-commits-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-dev@xmlgraphics.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Apache Wiki <wikidiffs@apache.org>
To: fop-commits@xmlgraphics.apache.org
Date: Thu, 08 Sep 2005 09:42:40 -0000
Message-ID: <20050908094240.29177.29639@ajax.apache.org>
Subject: [Xmlgraphics-fop Wiki] Update of "AreaTreeIntermediateXml" by
 JeremiasMaerki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.

The following page has been changed by JeremiasMaerki:
http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml

The comment on the change is:
First draft for a proposal on an intermediate XML format for Apache FOP

New page:
This page describes a proposal for an intermediate XML format in which FOP's area tree can be serialized and reread for delayed rendering. I've been approached by two parties who would like to have such a feature in FOP.

= Requirements =

 * The area tree should be serializable in an XML format so it can be easily manipulated.
 * The intermediate XML format should later be reread and normally rendered through FOP's Renderers.
 * It should be possible to combine XML files from multiple rendering runs into one document which is then rendered by FOP's Renderers.
 * The intermediate format should make it possible to add graphical elements after processing, for example for OMR marks and barcodes for packaging control.
 * Allow imposition functions, two-up, n-up, page overlays, scaling and rotation of whole pages.
 * One party that approached my wants to to manual modifications on leaf level to modify the appearance of the document, for example, squeezing in one more line of text or something like that. Adventurous, but if they are so brave... :-)
 * The implementation must not have a negative impact on performance for people who don't use the intermediate format.

= Benefits =

The intermediate format allows various manipulations of the layouted document. People can do stuff that they can't do during the XSL-FO stage and that they'd have to do by post-processing FOP's output, but after they already lost some information on the way (like the simple-page-master used by a page).

= Possible Problems =

 * The area tree is currently not 100% self-sufficient. There are references to the FO tree, for example.
 * Different renderers provide different font sources. Rendering a document with a different font source from the one the document was layouted with may produce unexpected results.

= Implementation notes =

 * The first step will be to make the area tree self-sufficient to make it really reloadable.
 * There is a !CachedRenderPagesModel which is supposed to save pages in a file as long as they can't be rendered. This class is currently not used and FOP, but it would be good to make sure this class works again which will be a long way towards making sure that the first step is done.
 * Serialization to XML can be implemented in two ways:
   * The XMLRenderer is used. The problem here is that the renderer would have to be changed here are there and almost certainly in a way that would make changes in many layout engine test cases necessary.
   * SAX-based serialization is implemented directly on the area classes. This basically means duplicate work when we already have the XMLRenderer but it places the functionality in the "right" place and leaves the freedom to design this format as needed by the tasks that will be performed with it.
 * The Bean-to-XML serialization available since JDK 1.4 cannot be used due to JDK restrictions.
 * It's probably best to implement parsing via SAX again to avoid dependencies on other XML libraries like Digester.
 * Adding a wrapper around a !PageViewport to do things like two-up and overlays should be easy. The Renderers will be teached to handle this additional wrapper object and will simply set up the target coordinate system accordingly. This will have no influence on the relative coordinate handling while rendering the actual area objects.
 * Foreign XML content (from i-f-o) will be serialized in their proper namespaces in the intermediate format. That allows the XMLHandlers to still optimize the rendering of foreign XML dialects. Some improvements in the infrastructure around this may be necessary, but should not be a big deal.
 * We will need to provide an API to handle the generation of the area tree XML. Furthermore, we need functions to load the intermediate format and to render it.
 * It should be noted that with this design, there will be no direct painting routines. Additional graphics will need to be included as !ForeignObjects in SVG or another format wrapped in a positioned Block area.

= Additional ideas =

 * Someone could come up with a FOP extension which includes an intermediate format XML file which could automatically be included at a certain point while rendering the main document (Document insertion). If someone implements PDF parsing, the same could be done for PDF.

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org