[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 4 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-fop : Java XML Framework - cocoon-block-tour : Java XML Framework - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - 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 -INFO- Failed to extract 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-23092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-23092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-23092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-23092005.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]
[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 4 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon-block-fop : Java XML Framework - cocoon-block-tour : Java XML Framework - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - 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 -INFO- Failed to extract 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-23092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-23092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-23092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-23092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-23092005.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]
Re: txt-rendering
Hi Sergey, that certainly sounds better although I'm not sure I really understand why exactly you need to do these refinements. I assume that the TextRenderer will also work for most cases without the special AreaTreeHandler. I'm looking forward to having a look at your patch when it's ready. On 23.09.2005 12:41:36 Sergey Simonchik wrote: Hi Jeremias, We don't have in mind to change or modify any code in layout engine or code of formatting objects itself. It's just suggested to have our own handler which extends AreaTreeHandler. This handler should do some refinement for txt (modifying tree of formatting objects, for example changing font-size, etc). We emphasize that TxtHandler, which extends AreaTreeHandler, is used only in txt case. The method createFOEventHandler() return different FOEventHandler and in case of txt output it should return TxtHandler. Good luck. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, September 22, 2005 7:11 PM To: fop-dev@xmlgraphics.apache.org Cc: 'Danila Ermakov' Subject: 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 Jeremias Maerki
Q: Padding props -- fixed lengths?
Hi, A question: I noticed that the warning about tables having padding and border-collapse=collapse has been commented out recently, since hasPadding() now requires context. Can anyone explain why precisely this was done? IOW: why does a PercentBaseContext *always* need to be provided? Why is hasPadding() not simply overloaded --one with a context, and one without? It almost makes it seem as if padding always needs to be specified as a percentage-width, or somehow a fixed-length is always interpreted as the specified fixed-length * 100%...? Thanks, Andreas
More page-height and -width: auto?
Hi, Another question related to page-height and page-width properties on simple-page-master: The Rec states that, in case the value is specified as auto: The 'page-height/-width' shall be determined, in the case of continuous media, from the size of the User Agent window, otherwise from the size of the media. If media information is not available this dimension shall be implementation-defined. upon which it suggests to use fallbacks of 11in x 8.26in. Now, I was thinking, since currently the fallback values are used as defaults --which, strictly speaking, is wrong-- maybe the first step towards implementing auto could be to define these fallbacks in fop.xconf (?) We'd properly set the default to EN_AUTO in FOPropertyMapping, and in case the FOUserAgent doesn't provide any values for them, the fallbacks in FOP's default configuration could be used, and a user could override these in his own userconfig.xml This would also be implementation-defined, but avoids hard-coding the fallback values. I'll gladly take a look at it, if enough people consider this to be sensible... WDYT? Cheers, Andreas
RE: txt-rendering
Hi Jeremias, May be it's impossible to understand our idea perfectly. Furthermore, we still haven't ICLA and so we can't commit patch with new file (unfortunately such file is 'TxtHandler.java'). Good luck. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 7:10 PM To: fop-dev@xmlgraphics.apache.org Cc: 'Danila Ermakov' Subject: Re: txt-rendering Hi Sergey, that certainly sounds better although I'm not sure I really understand why exactly you need to do these refinements. I assume that the TextRenderer will also work for most cases without the special AreaTreeHandler. I'm looking forward to having a look at your patch when it's ready. On 23.09.2005 12:41:36 Sergey Simonchik wrote: Hi Jeremias, We don't have in mind to change or modify any code in layout engine or code of formatting objects itself. It's just suggested to have our own handler which extends AreaTreeHandler. This handler should do some refinement for txt (modifying tree of formatting objects, for example changing font-size, etc). We emphasize that TxtHandler, which extends AreaTreeHandler, is used only in txt case. The method createFOEventHandler() return different FOEventHandler and in case of txt output it should return TxtHandler. Good luck. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, September 22, 2005 7:11 PM To: fop-dev@xmlgraphics.apache.org Cc: 'Danila Ermakov' Subject: 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 Jeremias Maerki
Another page-related question: page-position=last
Hi, (Apologies for the many posts... I'm definitely on a roll :-)) Now that it has been made clear to me that the layout-engine first calculates *all* break-possibilities, IMO this also seems to make implementing page-position=last much, much easier. Assuming that no areas are generated until the full element list is known, I'm thinking once you have created the Knuth-element list, instead of starting at element index zero to generate the areas, it would also be possible to have the algorithm start at the last element in the list until we reach the first break-possibility that would make the content exceed the height page-master whose page-position is last, no? At the very least, it would enable us to mark the break-possibility at which the algorithm should consider the last page-master... Obviously, we can't complete the full iteration in that direction, or we would run into problems determining the difference between odd and even, but it seems possible to iterate backwards once and assign a sort of 'favorability degree' to each of break-possibilities --increase or decrease penalty values?--, taking into account that the last page *has* to start somewhere after the marked one --before is impossible, since it won't fit. The generated last page can be thrown away (or serialized to be re-used if the marked possibility just happens to coincide with the actual last page-break). Am I getting this correctly? Cheers, Andreas
Re: Q: Padding props -- fixed lengths?
On Sep 23, 2005, at 18:12, Andreas L Delmelle wrote: snip / It almost makes it seem as if padding always needs to be specified as a percentage-width, or somehow a fixed-length is always interpreted as the specified fixed-length * 100%...? Or, more correctly: as if the fixed-length is converted to a percentage only to be recalculated, so that you end up with the exact same value...? Somehow this seems suboptimal. Let me know if I'm missing anything. Thanks, Andreas
Re: More page-height and -width: auto?
On Sep 23, 2005, at 18:32, Andreas L Delmelle wrote: Now, I was thinking, since currently the fallback values are used as defaults --which, strictly speaking, is wrong-- maybe the first step towards implementing auto could be to define these fallbacks in fop.xconf (?) Duh! I mean, we still have to hard-code it into FOUserAgent, but the intention is to provide the end-user with a way to set defaults himself, so that he can use auto and specify different values for the defaults if he wants to. So he can switch from A4 to Letter to A5 just by modifying the height and width values in his own config file, instead of explicitly specifying these in his FO source --although for one FO document, this seems to be no improvement, if you have a hundred you wish to render to A4 instead of Letter, this begins to make sense. Just use auto and modify the value once in your custom config. snip / I'll gladly take a look at it, if enough people consider this to be sensible... So I didn't wait for responses, but I'm a bit stuck ATM, since I'd like to make sure that the user can specify these values in a custom fop.xconf in the same format he would specify them in the FO source. I'd like to take advantage of the property parser here. More accurately (see thread about indefinite page-dimensions): As a first step, I'd like to provide a customized PageDimensionMaker, that checks for a specified or initial value of auto, and then returns a LengthProperty based on those defaults. (In the long term we should also take into account the Rec referring to the 'media information', but for now this should suffice.) The FOUserAgent is reachable to the Maker through FObj.getFOEventHandler().getUserAgent(), so no problem there, but how to proceed after fetching the String value... If anyone can offer any hints on this (before I figure it out myself ;-P), these would be much appreciated. TIA! Andreas
Re: Q: Padding props -- fixed lengths?
On Sat, 24 Sep 2005 03:45 am, Andreas L Delmelle wrote: On Sep 23, 2005, at 18:12, Andreas L Delmelle wrote: snip / It almost makes it seem as if padding always needs to be specified as a percentage-width, or somehow a fixed-length is always interpreted as the specified fixed-length * 100%...? Or, more correctly: as if the fixed-length is converted to a percentage only to be recalculated, so that you end up with the exact same value...? Somehow this seems suboptimal. Let me know if I'm missing anything. Andreas, I think this is a misunderstanding. Firstly you can specify a padding width in any way allowed by the spec. However, if you want to get the computed/absolute value anywhere you need to provide a context for percentage evaluation as the width in question could have been specified by the user as a percentage. The property system will only use the context if the specified value is a percentage otherwise it will ignore it. The case in question is tricky as the context is only available during layout but in this case a padding width is attempted to be evaluated during fo tree parsing. In the general case that can not be done as if the width is specified as a percentage you have to wait until layout to get typically the ipd on which the percentage is based. Therefore the whole logic of trying to determine hasPadding during fo tree construction is misplaced. This is further complicated by the possibility that the specified value can be an expression containing a percentage (eg. 5% - 5pt). There is no way to determine if this expression evaluates to 0 or not until layout. Thanks, Andreas HTH Manuel
