Re: [Xmlgraphics-fop Wiki] Update of BreakPossibilityBuilding by JeremiasMaerki
On Thu, 22 Sep 2005 02:36 pm, Apache Wiki wrote: Dear Wiki user, snip/ = Borders and Padding = - Borders and paddings are generally replicated on each page when block-level FO spans more than a page. Nesting FOs can cause multiple such marks to appear at the beginning and at the end of a page. For each break possibility inside an FO and for breaks between FOs that are nested under a parent breaking such marks these border and padding widths may have to be taken into account when building the element list for the break possibility, depending on their order. The first non-conditional length (counted from the edge of the reference area) will cause subsequent conditional lengths to appear in every case. + Borders and paddings are generally replicated on each page when a block-level FO spans more than a page. Nesting FOs can cause multiple such marks to appear at the beginning and at the end of a page. For each break possibility inside an FO and for breaks between FOs that are nested under a parent breaking such marks, these border and padding widths may have to be taken into account when building the element list for the break possibility, depending on their order. (The first non-conditional length (counted from the edge of the reference area) will cause subsequent conditional lengths to appear in every case. ''This last sentence is probably wrong!'') Jeremias, I was wondering about that myself when I read your page. My understanding is that the question if a border/padding is drawn or not is independent of any spaces surrounding it and what treatment they receive. That is the decision if a border/padding is drawn depends solely on its conditionality, and the respective is-first / is-last traits on the area in question. And yes, there is space-start/end stuff in the inline LMs which is broken but I would suggest to leave that until the space handling in bpd is sorted out. Manuel
Re: [Xmlgraphics-fop Wiki] Update of BreakPossibilityBuilding by JeremiasMaerki
Hey, I make mistakes. If you guys find anything wrong I hope you make me aware of it. Thanks for the feedback. I'd give a lot to beam one or two of you to my place to have a chance of discussing this face-to-face. On 22.09.2005 09:07:40 Manuel Mall wrote: On Thu, 22 Sep 2005 02:36 pm, Apache Wiki wrote: Dear Wiki user, snip/ = Borders and Padding = - Borders and paddings are generally replicated on each page when block-level FO spans more than a page. Nesting FOs can cause multiple such marks to appear at the beginning and at the end of a page. For each break possibility inside an FO and for breaks between FOs that are nested under a parent breaking such marks these border and padding widths may have to be taken into account when building the element list for the break possibility, depending on their order. The first non-conditional length (counted from the edge of the reference area) will cause subsequent conditional lengths to appear in every case. + Borders and paddings are generally replicated on each page when a block-level FO spans more than a page. Nesting FOs can cause multiple such marks to appear at the beginning and at the end of a page. For each break possibility inside an FO and for breaks between FOs that are nested under a parent breaking such marks, these border and padding widths may have to be taken into account when building the element list for the break possibility, depending on their order. (The first non-conditional length (counted from the edge of the reference area) will cause subsequent conditional lengths to appear in every case. ''This last sentence is probably wrong!'') Jeremias, I was wondering about that myself when I read your page. My understanding is that the question if a border/padding is drawn or not is independent of any spaces surrounding it and what treatment they receive. That is the decision if a border/padding is drawn depends solely on its conditionality, and the respective is-first / is-last traits on the area in question. And yes, there is space-start/end stuff in the inline LMs which is broken but I would suggest to leave that until the space handling in bpd is sorted out. Manuel Jeremias Maerki
[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 22 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-22092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-22092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-22092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-22092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-22092005.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: [Xmlgraphics-fop Wiki] Update of SpaceResolution/Examples by JeremiasMaerki
On Thu, 22 Sep 2005 09:14 pm, Apache Wiki wrote: snip/ The following padding is suppressed as is the space right after that. ''(not sure here)'' This is regarding Example 9: IMO padding is suppressed: Yes because is-first is false as it is the 2nd area generated for the outer block. space-before on inner block is suppressed: No - this is the first area generated from the inner block so is-first is true. It is also the first child of the outer area so 4.2.5 (1.) applies and there are no other space specifiers. Therefore at the start of the page after the page break I would expect: 1) The 2pt border (no space-before, no padding after) 2) A 6pt space 3) The text: second line HTH Manuel
RE: txt-rendering
Hi, We've got into TxtRenderer that was in 0.20.5. It works fine for most of examples but in some cases there are problems. For instance: ... fo:block text-align=right font-size=10ptHi/fo:block fo:block text-align=right font-size=50ptHelloworld/fo:block ... Align doesn't correct. It's seems that modifying formatting objects before constructing area tree model may help to cope with such problems. --Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 3:29 PM To: fop-dev@xmlgraphics.apache.org Cc: Danila Ermakov Subject: 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
Re: txt-rendering
Hi Sergey, would you please elaborate the modifications you suggest? I'd be very unhappy if we had to do changes in the layout engine just to accomodate the text renderer. I think I don't quite understand what you have in mind. Furthermore, I'm not sure if using different font-sizes in the case of the text renderer is a good idea. See also: http://xmlgraphics.apache.org/fop/output.html#txt On 22.09.2005 10:21:32 Sergey Simonchik wrote: Hi, We've got into TxtRenderer that was in 0.20.5. It works fine for most of examples but in some cases there are problems. For instance: ... fo:block text-align=right font-size=10ptHi/fo:block fo:block text-align=right font-size=50ptHelloworld/fo:block ... Align doesn't correct. It's seems that modifying formatting objects before constructing area tree model may help to cope with such problems. --Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Saturday, September 17, 2005 3:29 PM To: fop-dev@xmlgraphics.apache.org Cc: Danila Ermakov Subject: 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 Jeremias Maerki
Re: txt-rendering
Jeremias Maerki wrote: Hi Sergey, would you please elaborate the modifications you suggest? I'd be very unhappy if we had to do changes in the layout engine just to accomodate the text renderer. I think I don't quite understand what you have in mind. I tend to agree. If the Text Renderer requires specialized logic in Layout or FO Tree then it won't be possible to send an Area Tree representation to any renderer. Chris
Indefinite page-width / page-height
Hi, I took a quick stroll through the code, and now I'm really getting the impression that implementing indefinite page-width or page-height isn't all that hard to achieve. (Those enlightenments by Jeremias and Manuel yesterday sure gave me the kick that was needed to grasp what happens and why our current layout-engine is so darn' cool :-) ) The remark about running into a limitation WRT using int and millipoints, which definitely did put a smile on my face :-), doesn't seem to pose a problem, since the Integer.MAX_VALUE won't actually be used anywhere for measurements --just as a hint to the BreakingAlgorithm that there is no constraint on the page's height or width. Explicit breaks are still possible. Luca was very right in pointing out that the breaking algorithm can't be ignored. Running out of memory is indeed the more likely result, but my guess is that these properties weren't meant to be used to generate one outrageously looong page. They do come in handy if you want to make a nice electronic photo-album PDF, where each page doesn't necessarily have to have the exact same dimensions --implementing auto for page-width and -height is also a must if you don't want to end up with pages that are all 8in wide or 11in high. If the user forgot explicit breaks, then that's his concern --on a JVM with sufficiently large heap-size, he will surely curse himself when he first has to wait a couple of minutes only to realize that FOP crashes and didn't get to render *any* content :-) I'm definitely going to take a closer look soon, but right now I'll just add a few comments for future reference (in case I don't get around to it, someone else doesn't need to start from scratch) Things to do (first glance): 1) In the properties package we should already catch the case of both height and width being specified as indefinite, and letting the other default to auto (or the fallback: 11in or 8in), plus give a warning about this. Rough idea: use a PageDimensionMaker extending LengthProperty.Maker to deal with that --checks for the values of reference-orientation and writing-mode could also be added here (cfr. Rec 7.25.13 dependency on 'block-progression-direction') 2) In the area package, PageViewport currently sets the pageHeight and pageWidth unconditionally to the integer value of the respective Length instance variables of its SimplePageMaster. This should be changed to, say a default of -1 or zero in case of getEnum() == EN_INDEFINITE (?), since negative or zero values for page-height or -width make no sense (at least not to me, but the 1.0 Rec doesn't seem to enforce a positive non-zero value? [*]). Also, probably something like a setPageHeight() method should be added that allows the PageSequenceLM to feed the accumulated content-height or -width back into the PageViewport after the BreakingAlgorithm has done its work. 3) Similar remark as above for area.Page, which creates a FODimension unconditionally using the height and width integer values. 4) Should code be added to FODimension itself for dealing with the value indicating indefinite page-size? Might be better to subclass FODimension... I'm not sure yet. I guess not creating a FODimension at all would lead to NPE's being thrown. That's it for now. AFAICT, the BreakingAlgorithm as it currently works, requires only minimal modification to handle the rest without any problems. See what I mean: almost no changes to the layout-engine are needed --at most, use Integer.MAX_VALUE in PageSequenceLM.getAvailableBPD() if the BPD returned by the viewports turns out to be -1 or zero, and force the current PageViewport's height/width in a break-situation. Come to think of it, the first can most likely be handled by the viewports themselves. Cool! Cheers, Andreas [*] BTW: currently, if the height/width is explicitly set to a negative value, you get no real warning about this, but it does have its impact on the result... It can always happen, I guess, especially when the input FO comes from a complex XSL transformation, so it may be worthwhile to provide a reasonable fallback in those cases. For negative values, maybe we could flip the sign, for zero values the currently used fallbacks (8 or 11in) should be sufficient. This could be handled in the properties package without any problem.
