DO NOT REPLY [Bug 48534] New: java.lang.StringIndexOutOfBoundsException
https://issues.apache.org/bugzilla/show_bug.cgi?id=48534 Summary: java.lang.StringIndexOutOfBoundsException Product: Fop Version: all Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: antti.kara...@napa.fi both fop 0.95 and trunk version fail the attached fo file with C:\Temp\cr14230>\programs\Java\fop-trunk\fop.bat -fo testi.fo -pdf testix.pdf 13.1.2010 14:12:06 org.apache.fop.cli.Main startFOP SEVERE: Exception java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:302) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:686) at org.apache.fop.fo.properties.CharacterProperty$Maker.make(CharacterProperty.java:44) at org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:412) at org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:319) at org.apache.fop.fo.FObj.processNode(FObj.java:119) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:282) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:299) ... 3 more - java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:686) at org.apache.fop.fo.properties.CharacterProperty$Maker.make(CharacterProperty.java:44) at org.apache.fop.fo.PropertyList.convertAttributeToProperty(PropertyList.java:412) at org.apache.fop.fo.PropertyList.addAttributesToList(PropertyList.java:319) at org.apache.fop.fo.FObj.processNode(FObj.java:119) at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:282) at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:171) at org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:1072) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484) at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:299) at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:130) at org.apache.fop.cli.Main.startFOP(Main.java:174) at org.apache.fop.cli.Main.main(Main.java:205) (stack trace from trunk version as of 13. Jan 2010). It is likely something wrong with the given xsl-fo. It validates fine with XMLasdf Spy, but I would guess it's something e.g. in attribute values that goes undetected by it
DO NOT REPLY [Bug 48534] java.lang.StringIndexOutOfBoundsException
https://issues.apache.org/bugzilla/show_bug.cgi?id=48534 --- Comment #1 from Antti Karanta 2010-01-13 04:18:21 UTC --- Created an attachment (id=24835) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24835) Sample xsl-fo file to reproduce the bug -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48534] java.lang.StringIndexOutOfBoundsException
https://issues.apache.org/bugzilla/show_bug.cgi?id=48534 --- Comment #2 from Pascal Sancho 2010-01-13 04:46:01 UTC --- This issue is due to empty hyphenation-character property. hyphenation-character property should have either a or inherit value. I think that empty string is not a valid value. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48537] New: Wrong handling of blank pages, page-position="last" and force-page-count
https://issues.apache.org/bugzilla/show_bug.cgi?id=48537 Summary: Wrong handling of blank pages, page-position="last" and force-page-count Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: page-master/layout AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: vhenneb...@gmail.com When a blank page must be added to follow the force-page-count constraint, and a page-sequence-master has been defined for the last page, that page-sequence-master will be used for the next-to-last page instead, and the last page will be a blank page. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48537] Wrong handling of blank pages, page-position="last" and force-page-count
https://issues.apache.org/bugzilla/show_bug.cgi?id=48537 --- Comment #1 from Vincent Hennebert 2010-01-13 07:57:46 UTC --- Created an attachment (id=24838) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24838) First example. Blank page is added after last page instead of using normal p-s-m for page 2 and last-page for page 3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48537] Wrong handling of blank pages, page-position="last" and force-page-count
https://issues.apache.org/bugzilla/show_bug.cgi?id=48537 --- Comment #2 from Vincent Hennebert 2010-01-13 07:58:26 UTC --- Created an attachment (id=24839) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24839) PDF rendering of first example -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48537] Wrong handling of blank pages, page-position="last" and force-page-count
https://issues.apache.org/bugzilla/show_bug.cgi?id=48537 --- Comment #3 from Vincent Hennebert 2010-01-13 07:59:54 UTC --- Created an attachment (id=24840) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24840) Second example. Last-page too small to hold content, so added as page 3 and blank page as page 4 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48537] Wrong handling of blank pages, page-position="last" and force-page-count
https://issues.apache.org/bugzilla/show_bug.cgi?id=48537 --- Comment #4 from Vincent Hennebert 2010-01-13 08:00:22 UTC --- Created an attachment (id=24841) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24841) PDF rendering of second example -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 48538] New: Default value for column-gap is 18pt instead of 12pt
https://issues.apache.org/bugzilla/show_bug.cgi?id=48538 Summary: Default value for column-gap is 18pt instead of 12pt Product: Fop Version: all Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: fo tree AssignedTo: fop-dev@xmlgraphics.apache.org ReportedBy: vhenneb...@gmail.com The default value set in FOPropertyMapping for the column-gap property is 0.25in (18pt), whereas the XSL-FO Reference prescribes a default value of 12pt. While fixing this bug is easy, it may break a looot of user documents that rely on the default value of column-gap. Releasing a major version of FOP would probably be an opportunity to fix it, if other backwards-incompatible changes are to be expected anyway. Leaving this as a reminder meanwhile. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: change bar status
Dear all, sorry for the long delay in answering. Having had some time in the last days to actually continue working on the change bar stuff: + parsing and validating the fo:change-bar-begin and fo:change-bar-end elements works (including properties) + attaching to all fo: elements that are between fo:change-bar-begin and fo:change-bar-end elements the vector of change bars that affect the element is implemented If I understand the FO standard right, then for each area generated by a FO object under the influence of a change bar, an area (with correct border-style/width/color... settings) has to be created as an xsl-absolute area and placed as determined by the change bar style relative to the column or page edge. For areas generated in the body-region, these additional areas are children of the flow area, for after/before/start/end they are children of the respective area region. If I understand the FOP code right, the areas are actually constructed by the various layout managers in addAreas(). Now, when creating the change-bar areas, one could for every area thus constructed, add a change bar area at the correct position in the area tree. But, it is desireable to merge change bar areas, because many areas will simply be the same or be adjacent to each other down the page side and should thus be represented as a single area representing the union of these areas (as far as possible). Another point is that the change-bar areas have a "z-Buffer" trait that decides visibility of overlapping change bars: I am not sure how to handle that yet. Would it be best to really add the change bar areas when the originating areas are constructed and merge on the fly or would it be better to search for all change bar generating areas when the page is finished and then to perform the merge? Currently missing altogether are unit tests for the code I have added or changed. In short, we are getting somewhere. Best regards Stephan Original-Nachricht > Datum: Mon, 09 Nov 2009 18:09:06 +0900 > Von: Carlos Villegas > An: fop-dev@xmlgraphics.apache.org > Betreff: change bar status > There was some discussion about implementing change bars some weeks ago. > What's the current status? > > Thanks, > Carlos -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
FOP and large documents: out of memory
Hello, as is well-known, FOP can run out of heap memory, when large documents are processed (http://xmlgraphics.apache.org/fop/0.95/running.html#memory). I have the situation that the documents I have to process mandate a footer on each page that contains a "page X of Y" element and a TOC at the beginning of the document, i.e. FOP cannot layout the pages until all referenced page-citations are known, which is after the last page of the document. When page content is quite complicated (e.g. 2000 pages mostly full with tables), the heap space does not suffice to hold all pages until all references can be resolved, thus FOP aborts with out-of-memory. Since increasing the heap space does not always work (3 GB heap space was required in one example), I need a better solution for this. 1. "-conserve" option One alternative would be the "-conserve" option, which serializes the pages to disk and reloads them as needed. Although slow, this definitely would be a solution, if it worked, which it doesn't: Our documents include graphics (SVG, PNG), and the serialization with "-conserve" throws an exception, because some class in Batik is not serializable (e.g. "SVGOMAnimatedString" IIRR), thus the page is missing, causing FOP to abort later. Thus, Batik would have to be fixed for this. 2. Two passes Since the pages are kept because of unresolved references, one could do the same as e.g. LaTeX always did: process the document twice. In a first run, pages are discarded after layout, only the references for page-citations are kept and at the end reused for the second pass (when all pages for the citations are finally known). For the second run, these id-refs are initially loaded and no pages have to be kept. This would require more changes in FOP (and should definitely be made optional obviously). I would appreciate any comments or other suggestions ! Best regards Stephan -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Re: FOP and large documents: out of memory
On 13 Jan 2010, at 21:27, Stephan Thesing wrote: Hi Stephan, > Since increasing the heap space does not always work (3 GB heap space was > required in one example), I need a better solution for this. > > 1. "-conserve" option > One alternative would be the "-conserve" option, which serializes the pages > to disk and reloads them as needed. > Although slow, this definitely would be a solution, if it worked, which it > doesn't: > Our documents include graphics (SVG, PNG), and the serialization with > "-conserve" throws an exception, because some class in Batik is not > serializable (e.g. "SVGOMAnimatedString" IIRR), thus the page is missing, > causing FOP to abort later. > Thus, Batik would have to be fixed for this. I think FOP can be 'fixed' for this too. If that is really the only class that is causing trouble, then FOP could make a serializable subclass for it, and use that in the area tree, instead of Batik's default non-serializable implementation. Unless Batik really needs it, why fix it there? It would require some thought on a (de)serialization routine, though... But seems much easier/faster to implement than the two-pass approach, if time/effort is of the essence. Regards, Andreas mailto:andreas.delmelle.AT.telenet.be ---
Re: FOP and large documents: out of memory
Hi Andreas, Original-Nachricht > Datum: Wed, 13 Jan 2010 21:42:51 +0100 > Von: Andreas Delmelle > An: fop-dev@xmlgraphics.apache.org > Betreff: Re: FOP and large documents: out of memory > > On 13 Jan 2010, at 21:27, Stephan Thesing wrote: ... > > Our documents include graphics (SVG, PNG), and the serialization with > "-conserve" throws an exception, because some class in Batik is not > serializable (e.g. "SVGOMAnimatedString" IIRR), thus the page is missing, > causing > FOP to abort later. > > Thus, Batik would have to be fixed for this. > > I think FOP can be 'fixed' for this too. If that is really the only class > that is causing trouble, then FOP could make a serializable subclass for > it, and use that in the area tree, instead of Batik's default > non-serializable implementation. Unless Batik really needs it, why fix it > there? I don't think that can work, as that class is used in elements nested in classes of Batik that represent the SVG. I.e., FOP never instantiates it, but the Batik code does somewhere along the way of creating the SVG element that is actually used in the Area tree (I am not sure, if it is the only class that cannot be serialized, as the serialization is aborted as soon as the first non-serializable class is encountered.) Best regards Stephan -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
