xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pascal Sancho <pascal.san...@takoma.fr>
Subject Re: generating pdf fails depending on page layout order
Date Mon, 04 Jun 2012 08:05:07 GMT

I have focused on the 1st issue I found. May be there are other issues 

Le 01/06/2012 18:13, Rob Sargent a écrit :
> Thanks Pascal,
> Sort of glad to know it's not just me! Unfortunately I don't think you
> example minimal fo actually recreates my problem. I'm trying to get the
> "gallery" page to have NO text at all, whereas you working example has
> two line of text on the "gallery" page. The best I have attained is a
> single line of text on my gallery page by dialing in the margin-top to
> 10.82in (10.83in generates the same exception, using 10.5 pt
> TimesNewRomanPSMT).

With the XSL-FO attached to my previous email FOP throws a FOPException, 
and produces no output.
I've set both font-size and line-height to 1in (on fo:root), and the 
available b-p-d of the 1st page body is less than 2in 
(page-height="11in" - body/@margin-top="9in + 0.001pt"), so there is no 
place for line break. Can you check again that you tried that example?

> I should mention that in our production situation the textless gallery
> pages work just fine, except when preceded by our "three-side" layout.
> We have two symptoms: aside from the FOPException reported, in some
> cases a single line of text appears on the gallery page. Since, as I've
> said, I believe these two cases are related I have not generate the
> 'single line of text' example. That has it's own interesting story which
> I will refrain from telling at this time, except to confess the actual
> page-layout dimensions for the gallery pages:
> <fo:simple-page-master page-width="8.5in" page-height="11in"
> master-name="gallery6-page-3" margin="0.0in 0.0in 0.6in 0.833in">
> <fo:region-body margin-top="10.0in" margin-right="0.70in"
> margin-bottom="0.40in" column-gap="0.40in" column-count="2" />
> <fo:region-before precedence="true" extent="9.0in"
> region-name="header-gallery6-page-3" />
> </fo:simple-page-master>

for the body of gallery6-page-3:
b-p-d is 11in - 0 - 0.6in - 10in - 0.4in = 0,
so, in case of multi-line content, there is no room for line-break, that 
cause a FOP exception if i-p-d changes on next page (this is a FOP bug).

for each column:
i-p-d = (8.5in - 0 - 0.833in - -0.7in - 0.4in) / 2 = 3.2865in

If you leave a 0 b-p-d to force an empty page, you should ensure that 
computed i-p-d for the content (here each column) equals the one of the 
next page, the issue you are facing should not occur.

> <fo:simple-page-master page-width="8.5in" page-height="11in"
> master-name="three-side-page-11" margin="0.0in 0.0in 0.6in 0.833in">
> <fo:region-body margin-top="0.75in" margin-right="4.3585in"
> column-count="1" />
> <fo:region-before region-name="default-right-header" precedence="true"
> extent="0.50in" />
> <fo:region-end extent="3.465in" region-name="three-side-start-11" />
> </fo:simple-page-master>
> Please advise as to how to procede. Happy to register the failure you've
> isolated (though I don't understand why the "fail" case doesn't generate
> one-line of text on the first page?).Should I enter another on the
> negative interplay of the two page layouts?
> On 06/01/2012 03:15 AM, Pascal Sancho wrote:
>> Hi Rob,
>> sure you are facing a bug:
>> when there is no room on 1 page to insert a line-break, then, if IPD
>> change on next page, the described FOPException is thrown.
>> See the attached minimal XSL-FO: when you remove the expression
>> " + 0.001pt" from the margin-top value, it works like charm.
>> Can you please fill in a bug on FOP bug list, attaching this minimal
>> XSL-FO?
>> As a workaround, you should decrease the margin-top of your
>> simple-page-master "gallery6-page-3" (leaving room for 2 * line-height,
>> and/or add a break-before on the %block% that come in 1st place of
>> your page 4.
>> Le 01/06/2012 04:00, Rob Sargent a écrit :
>>> We're using FOP-1.0.
>>> Admittedly it may be a stretch to call these "simple" page layouts but
>>> the attached FOs show that the ordering of the page layouts can cause
>>> the generation of the pdf to fail. The fo-fails.xml exists with
>>> Caused by: java.lang.UnsupportedOperationException: Don't know how
>>> to restart at positionNonLeafPos:927(Flow@61f93f69[@id=]],
>>> NonLeafPos:399(BlockContainer@52ab9d99[@id=group-Normal Development
>>> and Anatomy of the Cerebral Commissures]],
>>> NonLeafPos:106(BlockContainer@e09d7b9[@id=]],
>>> NonLeafPos:7(Block@58a2b90b[@id=]], LeafPos:-1(pos=29,
>>> lm=Block@58a2b90b[@id=]])))))
>>> at
>>> org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:377)
>>> at org.apache.fop.layoutmgr.PageBreaker.doLayout(PageBreaker.java:85)
>>> at
>>> org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:107)
>>> at
>>> org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:238)
>>> at
>>> org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:120)
>>> at
>>> org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:349)
>>> at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:177)
>>> at
>>> com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(ToXMLSAXHandler.java:261)
>>> at org.jdom.output.SAXOutputter.endElement(SAXOutputter.java:1046)
>>> at org.jdom.output.SAXOutputter.element(SAXOutputter.java:903)
>>> at org.jdom.output.SAXOutputter.elementContent(SAXOutputter.java:1093)
>>> at org.jdom.output.SAXOutputter.elementContent(SAXOutputter.java:1067)
>>> at org.jdom.output.SAXOutputter.element(SAXOutputter.java:897)
>>> at org.jdom.output.SAXOutputter.output(SAXOutputter.java:621)
>>> at
>>> org.jdom.transform.JDOMSource$DocumentReader.parse(JDOMSource.java:476)
>>> at
>>> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIdentity(TransformerImpl.java:636)
>>> at
>>> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:707)
>>> ... 7 more
>>> Some explaintion of the intent: The "three-side-page-*" s-m-ps usurp a
>>> two-column text xsl-region body placing a static region over one of the
>>> columns and the gallery6-page-* attempt to set the size of the
>>> region-body to zero (creating a 'text-less' page).
>>> Note that the gallery6-page-* layout was recently reworked to be
>>> textless. Prior to that (developed originally in FOP-0.95) we had an
>>> inch of text available and detected no order dependency amongst the
>>> orderings of layouts.
>>> And yes the s-m-ps are generated on the fly by the xsl translation,
>>> whereby a static page definitions is loaded into a page-number specific
>>> master, also left/right adjusted.
>>> Furthermore, in other we also experience a single line of text on the
>>> gallery6-page-*s only when preceded by a three-side-page-* s-m-p. If
>>> necessary I will report that as a separate issue, but at this point I'm
>>> hoping both symptoms are tightly related.
>>> Any work-around much appreciated. If requested, I'm more than willing to
>>> report this as a bug. Unfortunately we cannot wait for FOP-1.1 but we
>>> could run off the trunk.
>>> As I see it the diffs in the two attached FO's are entirely in the
>>> static-regions as one would expect.
>>> We're at crunch time and could go back to the original definition of
>>> gallery6-page* but would /really/ rather not.


To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message