New Intermediate Format: How to handle extension attributes?
I'm seeking additional opinions on the following: The most important motivation for the new intermediate format is more performance for those who produce their print files based on prelayouted documents (without noticeably slowing down the direct rendering path, i.e. without intermediate format). Parsing the area tree XML format proved to be relatively slow. In the case of extension attributes, for example, they have to be identified as such and are put into a Map defined in AreaTreeObject. The renderer can then check the area object if there are any supported extensions and act on them. With the new IF there is no longer an object that holds those extension attributes. Similar to SAX, the XML content is transformed to method calls directly. For extension elements, there is IFDocumentHandler.handleExtensionObject(Object) which is fine and does its job well enough as it turned out during the implementation. I still have to buffer some of the objects until the process reaches the right point in time where the extension objects are actually used. But the impact is quite insignificant. What I'm currently trying to figure out is the best way to handle the extension attributes. There are several possible approaches: 1. Add a Map or Attributes parameter to each applicable IF method. If it's a Map, it has to be built from an Attributes instance coming from the XML parser (when IF is parsed). That costs time and is undesirable. Or if it's an Attributes instance, I have to build that up in the case we paint directly from the IFRenderer. That also costs a bit of time although that conversion is less significant when compared to the whole process. But the approach also clutters the API a bit with things that are not used in most of the cases. 2. Pack each extension attribute in a call to handleExtensionObject(Object). A possibility, but I will need additional tracking to associate an extension object with the actual IF element. For a page I'd have to do startPage() followed by zero or more handleExtensionObject() calls and make sure the extensions are properly handled. It would also make the IFSerializer more complicated and the IFParser still has to actively split IF namespace and other namespaces. That can't be it. 3. The IFDocumentHandler/IFPainter pair gets access to a context object where it can access to the currently applicable extension attributes. The context object would play adapter for the two different extension sources: Map from the area tree and Attributes from the IFParser. That would avoid any additional processing especially if no extension objects are present. The context object would be set on the IFDocumentHandler at the beginning. 4. is a variant of 3 in which case the foreign object adapter would be available through a ThreadLocal. Personally, I prefer option 3 as it's the easiest to understand. In this case, I'd probably remove set/getUserAgent() in favor of set/getIFContext() and provide access to the user agent through the IFContext to avoid cluttering the IFDocumentHandler interface. Any other opinions or additional ideas? If I hear nothing I'll implement option 3. Thanks, Jeremias Maerki PS: Happy Xmas!
Re: Configuring Netbeans - missing org.apache.fop.fonts
Hi, I was able to do a clean build in Netbeans 6.5. If I have time over the weekend, I'll update the wiki. There are a number of changes since netbeans 4 - It's actually a whole lot easier now. Phil -- View this message in context: http://www.nabble.com/Configuring-Netbeans---missing--org.apache.fop.fonts-tp21126843p21143676.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Ant build - mathxml example
Hi, I am trying to build the examples\mathml\ example. According to the notes in the lib folder, I need to place jeuclid.jar in the lib folder. However, the latest version is jeuclid-3.1.3.jar. I get a dependency error in ant: jeuclid-check: [echo] = [echo] jeuclid.jar is missing in the lib directory. [echo] You can download it at: http://sourceforge.net/projects/jeuclid/ [echo] = Do I need to change anything in the build file to get it to compile? Thanks Phil -- View this message in context: http://www.nabble.com/Ant-build---mathxml-example-tp21143725p21143725.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Ant build - mathxml example
The example MathML extension only works with JEuclid 1.0. The current JEuclid has its own MathML extension for FOP. On 23.12.2008 13:38:08 bonekrusher wrote: Hi, I am trying to build the examples\mathml\ example. According to the notes in the lib folder, I need to place jeuclid.jar in the lib folder. However, the latest version is jeuclid-3.1.3.jar. I get a dependency error in ant: jeuclid-check: [echo] = [echo] jeuclid.jar is missing in the lib directory. [echo] You can download it at: http://sourceforge.net/projects/jeuclid/ [echo] = Do I need to change anything in the build file to get it to compile? Thanks Phil -- View this message in context: http://www.nabble.com/Ant-build---mathxml-example-tp21143725p21143725.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: Ant build - mathxml example
Thanks Jeremias, You're always a great help. I have another question; In the examples folder, there are examples for using fo:instream-foreign-object. Is there any examples that show an fo extension that creates an area in the area tree where normal xsl:fo is not possible? Thanks again! Jeremias Maerki-2 wrote: The example MathML extension only works with JEuclid 1.0. The current JEuclid has its own MathML extension for FOP. Jeremias Maerki -- View this message in context: http://www.nabble.com/Ant-build---mathxml-example-tp21143725p21144055.html Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Ant build - mathxml example
An isolated example? No. But you could take a look at my fox:external-document extension. That one is an extension and creates areas using a special layout manager. Classes involved: - org.apache.fop.fo.extensions.ExternalDocument (extension object, FO tree part) - org.apache.fop.fo.extensions.ExtensionElementMapping (extension registration) - org.apache.fop.layoutmgr.ExternalDocumentLayoutManager (layout manager) - org.apache.fop.layoutmgr.LayoutManagerMapping But frankly, I don't think it's possible (without changing FOP) to actually implement an external plug-in that creates/uses a layout manager. What are you trying to do? On 23.12.2008 14:00:54 bonekrusher wrote: Thanks Jeremias, You're always a great help. I have another question; In the examples folder, there are examples for using fo:instream-foreign-object. Is there any examples that show an fo extension that creates an area in the area tree where normal xsl:fo is not possible? Thanks again! Jeremias Maerki-2 wrote: The example MathML extension only works with JEuclid 1.0. The current JEuclid has its own MathML extension for FOP. Jeremias Maerki -- View this message in context: http://www.nabble.com/Ant-build---mathxml-example-tp21143725p21144055.html Sent from the FOP - Dev mailing list archive at Nabble.com. Jeremias Maerki
Re: Ant build - mathxml example
Hi Jeremias, I am just trying to learn. I was interested in either writing an extension for the Table-Continuation-Label or take a shot at the trunk. A while back I was interested in getting the Table-Continuation-Label support working: http://www.nabble.com/Adding-Table-Continuation-Label-support-tc17316648.html#a17316648 So slowly I've been studying the code. My Java skills are basic, I usually work on small applications. As you know the fop project is very large and complex. Plus there is added burden of learning the pdf spec and xsl-fo spec. I am fascinated on how it all works and would like to contribute some day. Regards, Phil -- View this message in context: http://www.nabble.com/Ant-build---mathxml-example-tp21143725p21145234.html Sent from the FOP - Dev mailing list archive at Nabble.com.
