txt-rendering
Hi, We've put mind to txt-rendering. :) Evidently converting to txt isn't implemented yet. So, before code writing, it will be useful to discuss different approaches of implementing it. By this moment we've found 3 possible basic approaches. Here they are: 1) TxtRender extends AbstractRender and try to render AbstractTreeModel to txt format. This approach similar to PDF. But unfortunately txt format is much less flexible than PDF. Thus we need to modify area tree model in order to render it to txt format. Details: TxtRender extends AbstractRender and overloads some methods which process model. 2) The second idea is similar to RTF approach. TxtHandler extends FOEventHandler and handles formatting objects by his own without AreaTreeModel. This doesn't allow us to use advantages of LayoutManager, for example lines fragmentation. 3) The third approach consist of modifying formatting objects before constructing area tree model. After getting formatting objects we make a refinement consisting of some procedures. One of them is converting font's attributes to default value which most appropriate for txt render. As we have already realized its Courier 10. Details: TxtHandler extends AreaTreeHandler and overloads only one method - endPageSequence where refinement takes place. TxtRender extends AbstractRender and overloads some methods which process model. But unlike first approach we have to do much less because LayoutManager gets modified formatting objects and returns better result. We started developing third approach. Good luck.
[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 5 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: 2 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/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/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.4/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/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-17092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-17092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-17092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-17092005.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] 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:
Re: txt-rendering
Hi Sergey, unfortunately, you didn't notice the TXTRenderer that was in 0.20.5 [1]. The text renderer seems to work fine for many people who work with FOP 0.20.5. IMO it should be simple to port that renderer to FOP Trunk. The TXTRenderer currently found in FOP Trunk is only an empty shell which needs to be filled. I'd investigate that before doing any serious coding on a completely new TextRenderer. Please have a look at TXTRenderer and get back to us so we can sort out any details. The old TXTRenderer is capable of creating good output without any special handling in the area tree. You will also find discussion snippets around the TXTRenderer in the mailing list archives which should give you an idea about its design. BTW, I'm glad that you're going to reintroduce the TextRenderer. AFAIK, there's still a open issue with a patch [2] where I asked you to send in an ICLA so I can commit the patch. So far, I haven't seen an ICLA being recorded with your name. [1] http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/branches/fop-0_20_2-maintain/src/org/apache/fop/render/txt/ [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=36480 On 17.09.2005 12:35:56 Sergey Simonchik wrote: Hi, We've put mind to txt-rendering. :) Evidently converting to txt isn't implemented yet. So, before code writing, it will be useful to discuss different approaches of implementing it. By this moment we've found 3 possible basic approaches. Here they are: 1) TxtRender extends AbstractRender and try to render AbstractTreeModel to txt format. This approach similar to PDF. But unfortunately txt format is much less flexible than PDF. Thus we need to modify area tree model in order to render it to txt format. Details: TxtRender extends AbstractRender and overloads some methods which process model. 2) The second idea is similar to RTF approach. TxtHandler extends FOEventHandler and handles formatting objects by his own without AreaTreeModel. This doesn't allow us to use advantages of LayoutManager, for example lines fragmentation. 3) The third approach consist of modifying formatting objects before constructing area tree model. After getting formatting objects we make a refinement consisting of some procedures. One of them is converting font's attributes to default value which most appropriate for txt render. As we have already realized its Courier 10. Details: TxtHandler extends AreaTreeHandler and overloads only one method - endPageSequence where refinement takes place. TxtRender extends AbstractRender and overloads some methods which process model. But unlike first approach we have to do much less because LayoutManager gets modified formatting objects and returns better result. We started developing third approach. Good luck. Jeremias Maerki
Re: Initial values for column-number (commit still pending...)
On Sep 16, 2005, at 16:31, Andreas L Delmelle wrote: YES! Got it. Ok, so I ended up thoroughly revising my approach, to account for the starts-row/ends-row issue that was the topic of this thread. One thing I also hadn't considered, but which I also succeeded in dealing with now, is out-of-order column-numbers. The note in the Rec about there not being a requirement for column-numbers to be 'monotonically increasing' also seems to imply that an author is allowed, in theory, to do the following: fo:table fo:table-column column-number=5 / fo:table-column column-number=2 / fo:table-column column-number=4 / fo:table-column column-number=3 / fo:table-column column-number=1 / ... Admitted, I would never, ever do this myself, but it seems to be permitted, so I thought I'd provide support for this anyway. In the following case then fo:table fo:table-column column-number=5 / fo:table-column column-number=2 / fo:table-column / fo:table-column / fo:table-column column-number=1 / ... the column-numbers for the third and fourth column in the above sequence would default to '3' and '4' respectively, just as the Rec mandates: the column-number of the previous column plus one. (Note that if the column-number of the second column weren't specified, this would default to '6', and for the third and fourth, the initial values would then become '7' and '8'...) One more question before I can wrap this up (about tables without explicit columns): Should the number of implicit columns be considered body-per-body? If not, and the table has no header, but it does have a footer, can the first row of the footer be considered the basis for determining the number of implicit columns? Maybe a quite exotic case, which I personally would avoid, but you never know... Perhaps, this isn't even worth considering at that point. We could just assign the column-numbers on row-per-row basis, and have layout complain about this in case of fixed table-layout if a row that is not the first one contains more cells than there are in the first row (which currently already happens IIC?) One other issue I didn't solve yet, but this was already a problem before my modifications, is a specified column-number that is negative or zero. Note: one of the consequences of my modifications will be that a zero-value will only occur in case it was explicitly specified by the user. Again, I would personally avoid this at all costs, and make the stylesheet such that this could never occur, but you never know... According to the Rec, this is no real error. The column-number should, in that case, be rounded to the nearest integer value greater than or equal to 1 (which I personally would interpret as: the nearest available non-occupied column-number). Currently, a PropertyException is thrown for this in TableColumn.bind(). Now, it's a piece of cake to force the columnNumber instance variable of the column in question, but in order to make it pass an eventual FOTree test, this should be dealt with while creating the property itself --so that it's already correct in the PropertyList. Maybe in that case, I'd need to provide more than just a custom PropertyMaker...? Well, in order to evaluate that, it's probably best to wait until my commit --finally-- comes through. Cheers, Andreas
Re: svn commit: r280872 - in /xmlgraphics/fop/trunk/test/layoutengine: disabled-testcases.txt testcases/block_padding_2.xml
I see my error; I did not realize the influence of the retained padding. This situation is very similar to tables with their headers and footers. There needs to be a penalty equal to the widths of the padding-after and padding-before below each block. A block equal to the widths of the padding-after and padding-before comes at the end of the block. I do not have time to look up the details, as I am going away for a few days. Regards, Simon On Thu, Sep 15, 2005 at 08:58:37AM +0200, Jeremias Maerki wrote: On 14.09.2005 22:44:07 Simon Pepping wrote: On Wed, Sep 14, 2005 at 05:05:37PM +0200, Jeremias Maerki wrote: Can one of the Knuth specialist please review my element list in the new test case below? Thanks. The element list seems OK to me. The first page also seems OK to me. What is strange is that the first line on the second page has vpos=190800, i.e. 6 below the end of the last line on page 1. Clearly 3 padding after and padding before are added. Is this not a problem of the area part of the code? I didn't even look at the area tree, but you're right vpos is a bit strange, though I get 162000, not 190800. :-) But I wouldn't put too much weight on the vpos attribute since it simply writes out the currentBPPosition. I'm going to investigate that a little more. I believe we can't start talking about something wrong in the area part if the element list is wrong in the first place. Both parts need to be synchronized. That's why it's important not only to test the area tree but also the element lists. Otherwise, you get strange line or page breaking decisions and you don't know why. Thanks for the feedback! I realized with this bug that I need to take borders and padding from parent LMs into account when I'm trying to create the right element lists for spaces. Looks like we need a stack on the LayoutContext for non-conditional borders and paddings. ATM I believe we will end up extending the use of unresolved list elements which get resolved to normal Knuth elements prior to breaking. Otherwise, the code gets too complicated if the complex break possibilities (like pen-glue-box-PEN-glue) are becoming more common. I will write something up on the Wiki about that. BTW, if you run this test, the output looks good, but add two or three additional lines and you'll see the problem in the output, too. Regards, Simon Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
How do I get the height of a character?
The font class provides a width method to determine the width of a character but how do I figure out the height of a character? Background: In my quest to get all the inline dimensions right so any background/border/padding is correctly applied I am currently looking at leaders. For leader-style=dots everything is basically user agent defined. Fop uses the dot character from the current font which is a sensible selection IMO. The bdp of the content-rectangle for a leader area is determined by the rule-thickness trait. In this case the rule thickness would be the height of the dot character. How do I figure that out? For the time being I will simply use the width of the dot character as its height. Manuel
