Fw: XSL 1.1 CR test suite available
Test suite available, yes, but when you look at the contents you will be disappointed. The tests only cover new features in 1.1 and some of the elements clarified since 1.0. I just gave it a test run. FOP doesn't look too good, mostly because the new 1.1 features are largely unimplemented, but also due to the lack of support for fo:inline-container which is used quite extensively. Furthermore, fo:wrapper is implemented as an inline layout manager but it can also be used for wrapping block-level FOs (result: ClassCastExceptions). The bookmark test, for example, uses lots of naked block-level wrappers which don't have any effect other than to make FOP fail. :-( When you remove the wrappers, everything's fine. Given the current results and the contents of the test suite, I'm not quite motivated enough to write some code so we can automate the test suite. If anyone else is, feel free. --- Original Message --- From:Grosso, Paul Date:Tue, 30 May 2006 15:30:51 -0400 Subject: XSL 1.1 CR test suite available The XSL FO SG has made available a test suite for the XSL 1.1 Candidate Recommendation. See http://www.w3.org/Style/XSL/TestSuite1.1/ for the Test Suite home page (which points to a zip and various other files). Though the minimum review period on the XSL 1.1 CR ends tomorrow, implementation feedback is necessary before we can request that XSL 1.1 become a Proposed Recommendation. The SG requests implementor feedback on the XSL 1.1 CR at http://www.w3.org/TR/2006/CR-xsl11-20060220/ All implementors and other interested parties are asked to provide feedback using the test suite as described in http://www.w3.org/Style/XSL/TestSuite1.1/w3cxsl-fo-1_1-test.html Comments on the test suite itself are also solicited. Paul Grosso for the XSL FO SG - Original Message Ends Jeremias Maerki
Re: Renderer feedback
Jeremias Maerki schrieb: I think the AFP and PCL renderers are now pretty much ready to be promoted from the sandbox. Are there any people on this list who have tried those renderers so they could give some feedback? I tried the PCL renderer with a few documents on a Brother HL1270N and those looked good but there were small differences with the PS versions. I'll hope to find some time soon to have a closer look at this. Christian
Re: [GSoC] Wiki page for progress informations
Jeremias Maerki wrote: did you already investigate how footnotes are implemented? Can you say anything about how similar the problem of footnotes is to before-floats? Just so you don't have to start from scratch while there may be something to build upon. After all, the footnotes also contain some logic to move certain parts to a different page than where anchor is located. A few quick comments about the footnote implementation: 1) the FootnoteLM returns only the sequence of elements representing the inline part (not the footnote-body part); it just adds to the last (inline) box a reference to the FootnoteBodyLM. 2) the LineLM, after computing the breaks, adds to each (block) box representing a line the references to the FootnoteBodyLM whose citations are in that line 3) during the remaining of the element collection phase, these references are not used (but in the creation of combined element lists, when they should be copied inside the new elements) 4) the PageSequenceLM.PageBreaker.getNextKnuthElements() method, after receiving all the (block) elements, scans them looking for footnote information, gets the elements from the referenced FootnoteBodyLM and puts them in a different list (at the moment a list of lists, but this is sub-optimal), and from the footnote-separator (in a separate list) 5) these lists are looked at in PageBreakingAlgorithm.computeDifference(), where we try to add some footnote content to the normal page content using getFootnoteSplit(), and in computeDemerits(), where some extra demerits are added if we break a footnote or some footnotes are deferred. This last point at the moment is performed using many PageBreakingAlgorithm private variables, which is maybe not the best way to do it, as we must be very careful about their initialization and their use, especially when the algorithm restarts. I think that a state object storing these variables could be used to store these values, and explicitly passed along the methods instead of relying on the class members, but concerning this I'd like to hear the opinions of the other committers ... Insertion of before-floats could be implemented in a similar way, giving the precedence to the footnote insertion (as it is affected by more strict constraints). An important difference between a footnote and a before-float is that the latter does not have an inline part, so (if we want to follow the same pattern) we need to either store the reference inside a previously-created box or to add some new elements containing the reference (but we must be sure that these elements cannot be parted from the previous ones, see the constraints in section 6.10.2 in the spec). A crucial point is the demerit function as, if I remember correctly, it greatly affect the computational complexity of the breaking algorithm (thre should be a M. Plass paper concerning this). HTH Another thing that we may need to keep in mind: There was lots of desire from the user community that FOP supports large documents (long-term goal, not necessary yours). I wrote that a first-fit algorithm could help free memory earlier. Obviously, for complex before-float situations a total-fit approach is probably more interesting as it can come up with more creative solutions. I'm just mentioning it so we keep the bigger picture in mind and since there could be conflicting goals. A first degree of first-fit algorithm could be achieved quite quickly by having a BreakingAlgorithm interface which is implemented by a TotalFitBA (the existing implementation) and a FirstFitBA which would have a much simpler considerLegalBreak() method that, instead of the complex set of nodes, just keeps in mind a single node. This would surely decrease the memory footprint, but is not (I think) what we really want, as this simplified algorithm would be performed on the whole sequence of elements. In order to start processing the sequence as soon as we receive a few elements we need to do some deeper changes. An idea (I just had it now, so I did not fully consider all its implications). At the moment, the block-level LM collect elements from their children and return just a single sequence (if there are no break conditions); we could have a parameter requesting them to return after they receive each child sub-sequence, and have a canStartComputingBreak() method that returns true if the sequence contains enough elements and we are using a first-fit algorithm, or false otherwise ... Sorry for the long post ... and for the long absence too, but it seems that just after thinking great, now I've really got some time to spend on FOP I receive tons of other things to do ... :-( Regards Luca
[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 17 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-31052006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-31052006.jar - Buildfile: build.xml init-avail: init-filters-jdk14: [echo] JDK 1.4 present. [copy] Copying 1 file to /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen init-filters-jdk13: init: [echo] --- Fop 0.20.5 [1999-2003] [echo] Apache Ant version 1.7alpha compiled on May 31 2006 [echo] VM: 1.5.0_06-b05, Sun Microsystems Inc. [echo] JAVA_HOME: /opt/jdk1.5 prepare: [echo] Preparing the build directories [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/svg [mkdir] Created dir:
[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project xml-fop-maintenance has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 17 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - xml-fop-maintenance : XSL-FO (Formatting Objects) processor (Maintenance branch) Full details are available at: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [fop.jar] identifier set to project name -INFO- Made directory [/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes] -INFO- Failed with reason build failed -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build) Work ended in a state of : Failed Elapsed: 3 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only gump [Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance] CLASSPATH: /opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-31052006/lib/batik-gvt.jar:/usr/local/gump/public/workspace/excalibur/framework/api/target/excalibur-framework-api-31052006.jar:/usr/local/gump/public/workspace/excalibur/framework/impl/target/excalibur-framework-impl-31052006.jar - Buildfile: build.xml init-avail: init-filters-jdk14: [echo] JDK 1.4 present. [copy] Copying 1 file to /x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen init-filters-jdk13: init: [echo] --- Fop 0.20.5 [1999-2003] [echo] Apache Ant version 1.7alpha compiled on May 31 2006 [echo] VM: 1.5.0_06-b05, Sun Microsystems Inc. [echo] JAVA_HOME: /opt/jdk1.5 prepare: [echo] Preparing the build directories [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts [mkdir] Created dir: /x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/svg [mkdir] Created dir:
Re: [GSoC] Wiki page for progress informations
Thanks a lot Luca! This will help me find my way in the code. I keep your comments in mind for when I better understand the whole issue. Vincent Luca Furini a écrit : Jeremias Maerki wrote: did you already investigate how footnotes are implemented? Can you say anything about how similar the problem of footnotes is to before-floats? Just so you don't have to start from scratch while there may be something to build upon. After all, the footnotes also contain some logic to move certain parts to a different page than where anchor is located. A few quick comments about the footnote implementation: 1) the FootnoteLM returns only the sequence of elements representing the inline part (not the footnote-body part); it just adds to the last (inline) box a reference to the FootnoteBodyLM. 2) the LineLM, after computing the breaks, adds to each (block) box representing a line the references to the FootnoteBodyLM whose citations are in that line 3) during the remaining of the element collection phase, these references are not used (but in the creation of combined element lists, when they should be copied inside the new elements) 4) the PageSequenceLM.PageBreaker.getNextKnuthElements() method, after receiving all the (block) elements, scans them looking for footnote information, gets the elements from the referenced FootnoteBodyLM and puts them in a different list (at the moment a list of lists, but this is sub-optimal), and from the footnote-separator (in a separate list) 5) these lists are looked at in PageBreakingAlgorithm.computeDifference(), where we try to add some footnote content to the normal page content using getFootnoteSplit(), and in computeDemerits(), where some extra demerits are added if we break a footnote or some footnotes are deferred. This last point at the moment is performed using many PageBreakingAlgorithm private variables, which is maybe not the best way to do it, as we must be very careful about their initialization and their use, especially when the algorithm restarts. I think that a state object storing these variables could be used to store these values, and explicitly passed along the methods instead of relying on the class members, but concerning this I'd like to hear the opinions of the other committers ... Insertion of before-floats could be implemented in a similar way, giving the precedence to the footnote insertion (as it is affected by more strict constraints). An important difference between a footnote and a before-float is that the latter does not have an inline part, so (if we want to follow the same pattern) we need to either store the reference inside a previously-created box or to add some new elements containing the reference (but we must be sure that these elements cannot be parted from the previous ones, see the constraints in section 6.10.2 in the spec). A crucial point is the demerit function as, if I remember correctly, it greatly affect the computational complexity of the breaking algorithm (thre should be a M. Plass paper concerning this). HTH Another thing that we may need to keep in mind: There was lots of desire from the user community that FOP supports large documents (long-term goal, not necessary yours). I wrote that a first-fit algorithm could help free memory earlier. Obviously, for complex before-float situations a total-fit approach is probably more interesting as it can come up with more creative solutions. I'm just mentioning it so we keep the bigger picture in mind and since there could be conflicting goals. A first degree of first-fit algorithm could be achieved quite quickly by having a BreakingAlgorithm interface which is implemented by a TotalFitBA (the existing implementation) and a FirstFitBA which would have a much simpler considerLegalBreak() method that, instead of the complex set of nodes, just keeps in mind a single node. This would surely decrease the memory footprint, but is not (I think) what we really want, as this simplified algorithm would be performed on the whole sequence of elements. In order to start processing the sequence as soon as we receive a few elements we need to do some deeper changes. An idea (I just had it now, so I did not fully consider all its implications). At the moment, the block-level LM collect elements from their children and return just a single sequence (if there are no break conditions); we could have a parameter requesting them to return after they receive each child sub-sequence, and have a canStartComputingBreak() method that returns true if the sequence contains enough elements and we are using a first-fit algorithm, or false otherwise ... Sorry for the long post ... and for the long absence too, but it seems that just after thinking great, now I've really got some time to spend on FOP I receive tons of other things to do ... :-( Regards Luca
OpenDocument as an output format
hi folks, creating an Output Handler for OASIS OpenDocument, as mentioned in the wish list don´t seem to make much sense, as XSL:FO can easily be converted to OpenDocument using a XSLT style sheet. without doing all that rendering in between ;) best regards stefan ziel clan informatica do brasil
Re: svn commit: r410672 - in /xmlgraphics/fop/trunk/src: documentation/content/xdocs/trunk/ java/org/apache/fop/fonts/ java/org/apache/fop/render/java2d/ sandbox/org/apache/fop/render/pcl/
I'd like to add some comments here: I'm a bit disappointed by PCL. While it is quite feature-rich, it has some important gaps. Examples are restrictions for handling transparent images at least in PCL5 (PCL5c seems to be a little better but is also quite a bit more complicated). Another example is the lack of sophisticated clipping (non-rect clipping areas) in HP GL/2. It's practically impossible to implement a full native Graphics2D implementation for HP GL/2. PCL contains support for TrueType fonts or downloading bitmap fonts, but implementing these is quite some work and not even the Windows PCL printer drivers seem to really do this. All examples I've generated so far made extensive use of bitmap painting much like what I resorted to in many areas now. And that despite setting on the printer driver which would suggest otherwise. At some point you really only paint bitmaps so you could just as well use the BitmapRenderer and wrap the bitmap in a PCL wrapper to handle painting on a desktop printer including tray selection. It would most likely be faster than the mix of bitmaps and native ops. Ok, it depends on the document. It is certainly possible to invest more time in a more sophisticated implementation (I've taken a few shortcuts along the way), but I doubt they are worth the effort. On 31.05.2006 23:17:19 jeremias wrote: Author: jeremias Date: Wed May 31 14:17:18 2006 New Revision: 410672 URL: http://svn.apache.org/viewvc?rev=410672view=rev Log: Improved accuracy of font size selection. The font size is not rounded down to the next integer point value anymore. (Java2D renderers profit from that one, too) PCL Renderer: Found a use case for that Java2D ascent value (which I call MaxAscent). It is used for painting text as bitmaps and to make sure the image the text is painted on is big enough if the font ascends beyond the em box. For non-Java2D fonts, MaxAscent is the same as ascent. Added a check that lets text painting fall back to bitmaps if there are characters that are not in the ISO-8859-1 encoding. This also enables Symbol and ZapfDingbats fonts. A text-rendering setting allows to disable PCL text painting in case the mix of PCL and bitmap text painting should result in unwelcome output. Note: the bitmap rendering is relatively slow (many small bitmaps). In the end we might end up rendering using a BitmapRenderer and only wrapping the whole thing in PCL (much like the Windows PCL drivers do). This would be faster than creating many small bitmaps. snip/ Jeremias Maerki
Re: OpenDocument as an output format
That's a fair comment. Still, you have to deal with ODF's ZIP-based container, multiple output files and resources. You won't get around writing some helper code around the XSLT. The other question is whether you can handle all the FO tree features (like inheritance) easily in XSLT. Any interest on your side to look into this? On 31.05.2006 21:17:26 Stefan Ziel wrote: hi folks, creating an Output Handler for OASIS OpenDocument, as mentioned in the wish list don´t seem to make much sense, as XSL:FO can easily be converted to OpenDocument using a XSLT style sheet. without doing all that rendering in between ;) best regards stefan ziel clan informatica do brasil Jeremias Maerki
