I also notice the following listed at [1]: *inline_block_nested_3.xml* (NPE for table inside an inline): Placing a table as a child of an fo:inline produces a NullPointerException.
[1] http://xmlgraphics.apache.org/fop/1.0/knownissues_overview.html On Wed, Mar 14, 2012 at 1:45 PM, Glenn Adams <[email protected]> wrote: > It looks like this bug was already reported at > > https://issues.apache.org/bugzilla/show_bug.cgi?id=47192 > > I added the trimmed down version of your FO file to this bug report as an > attachment. > > > 2012/3/14 Glenn Adams <[email protected]> > >> I believe it is a bug, and am getting ready to create one (if not already >> there). However, in the mean time, you may be able to work around it by >> eliminating the inline. >> >> In the future, it is best to trim down the test file to the minimum >> necessary to demonstrate the error. I have done this in the attached. >> >> >> On Wed, Mar 14, 2012 at 1:20 PM, Thomas Morrison < >> [email protected]> wrote: >> >>> Thanks, Glenn, for the quick response. I have been experimenting too, >>> but am nowhere near an expert on FO. (I have a customer wanting to use XML >>> publishing.)**** >>> >>> ** ** >>> >>> The document was created using Stylus Studio using the WYSIWYG editor. >>> I will retrace my steps to see where I created the fo:inline (which does >>> seem rather useless).**** >>> >>> ** ** >>> >>> It is interesting to note, though, that 0.20.5 and RenderX (as delivered >>> in Stylus Studio) both render this in the ‘expected’ manner.**** >>> >>> ** ** >>> >>> I will test your work around and get the information to the customer. >>> Maybe we will just have to add ‘remove fo:inline’ as part of the recipe. >>> **** >>> >>> ** ** >>> >>> Tom**** >>> >>> ** ** >>> >>> *From:* Glenn Adams [mailto:[email protected]] >>> *Sent:* Wednesday, March 14, 2012 2:12 PM >>> *To:* [email protected] >>> *Cc:* Thomas Morrison >>> *Subject:* Re: tablePositions empty assertion error in version 1.0**** >>> >>> ** ** >>> >>> A little experimentation quickly shows:**** >>> >>> ** ** >>> >>> (1) removing all but one row doesn't change behavior; however**** >>> >>> (2) removing the fo:inline parent that contains the table (and moving >>> the font size property to the parent fo:block) fixes the problem**** >>> >>> ** ** >>> >>> Did you really intend to nest the table in an inline?**** >>> >>> ** ** >>> >>> G.**** >>> >>> ** ** >>> >>> On Wed, Mar 14, 2012 at 11:17 AM, Thomas Morrison < >>> [email protected]> wrote:**** >>> >>> The attached fo document causes the tablePositions assertion, requesting >>> that the fo be sent. >>> >>> The full output of the rendering is: >>> >>> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener >>> processEvent >>> WARNING: Font "Symbol,normal,700" not found. Substituting with >>> "Symbol,normal,400". >>> Mar 14, 2012 11:40:07 AM org.apache.fop.events.LoggingEventListener >>> processEvent >>> WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with >>> "ZapfDingbats,normal,400". >>> Mar 14, 2012 11:40:07 AM >>> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas >>> SEVERE: tablePositions empty. Please send your FO file to >>> [email protected] >>> >>> The table-header is rendered at the end of the table. >>> >>> --- >>> >>> The PDF is renedered the same on 0.95, although the output is different, >>> not mentioning the two WARNINGs: >>> Mar 14, 2012 11:51:29 AM >>> org.apache.fop.layoutmgr.table.TableContentLayoutManager addAreas >>> SEVERE: tablePositions empty. Please send your FO file to >>> [email protected] >>> >>> --- >>> >>> The table-header is rendered correctly in 0.20.5 with the following >>> output: >>> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser >>> [INFO] FOP 0.20.5 >>> [INFO] Using org.apache.xerces.parsers.SAXParser as SAX2 Parser >>> [INFO] building formatting object tree >>> [INFO] setting up fonts >>> [INFO] [1] >>> [WARNING] Sum of fixed column widths 500000 greater than maximum >>> specified IPD 0 >>> [INFO] [2] >>> [INFO] Parsing of document complete, stopping renderer >>> >>> I have searched for a possible cause, and would like a workaround if not >>> a fix. I have so far been unable to determine what aspect of the table >>> header may be triggering this behavior. >>> >>> Tom Morrison >>> This message has been scanned by MailController - >>> portal1.mailcontroller.co.uk >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected]** >>> ** >>> >>> ** ** >>> >>> This message has been scanned by >>> MailController<http://portal1.mailcontroller.co.uk/> >>> .**** >>> >>> **** >>> >> >> >
