You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Vincent Hennebert <vh...@gmail.com> on 2011/04/01 15:36:35 UTC
Re: what might be forcing an early page/column break
Rob sent me his document offline and after some investigation
I identified the issue: this is due to the keep-with-next property set
on the last block of the document (and possibly its descendants). If you
remove them then the document renders normally. They are unnecessary
anyway, although I understand that this will complicate the XSLT part.
Why on Earth does the keep on the last block have an influence on
earlier elements? This is because of the infamous ‘Changing IPD hack’
i.e., support for pages of different widths. Whenever a change of page
width is detected, the remaining content is re-processed and it appears
that some things are not properly reset.
I’ll try and implement a fix soon. Meanwhile, the workaround I suggested
above might do.
HTH,
Vincent
On 23/03/11 15:40, Rob Sargent wrote:
> I suspect your basic premise, widow control, is correct. I've added enough
> text to the paragraph to force the original widow back on the the preceding
> paragraph. And there is still more room in the preceding column (4 lines
> worth, according to the column to the left) but I still get "two lines worth"
> placed on the following column.
>
> Could there be some implicit attachment of the block (or surrounding
> block-container) to the following heading? or the definition of the heading?
>
> I've attached the stylesheet (not the most straight forward xsl ever, I admit)
> but the pertinent parts are here.
>
>>>>>>This block-container wraps a series of "paragraphs"
>
> <xsl:template match="//preamble" priority="2">
> <xsl:choose>
> <xsl:when test="@ff_level='ff1'">
> <xsl:call-template name="build-toc"/>
> <fo:block-container font-family="{$preamble1-font}"
> font-size="{$preamble1-font-size}" space-before="12pt" padding-after="18pt"
> hyphenate="true" language="en_US">
> <xsl:apply-templates select="*"/>
> </fo:block-container>
> </xsl:when>
> <xsl:otherwise>
> <fo:block font-family="{$main-text-font}"
> font-size="{$main-text-font-size}" font-weight="normal">
> <xsl:apply-templates select="*[name(.) !=
> 'related-references']"/>
> </fo:block>
> </xsl:otherwise>
> </xsl:choose>
> </xsl:template>
>
>>>>>>This defines a "paragraph":
>
> <xsl:template match="//paragraph" priority="2">
> <fo:block space-before="{$pre-para-space}" text-align="{$right-edge}">
> <xsl:value-of select="text()"/>
> <xsl:call-template name="handle-references">
> <xsl:with-param name="current" select="."/>
> </xsl:call-template>
> </fo:block>
> </xsl:template>
>
>>>>>>And this is the heading which follows.
> <xsl:template match="//dx-group">
> <xsl:call-template name="header-h2">
> <xsl:with-param name="groupName" select="text()"/>
> </xsl:call-template>
> <fo:block-container font-size="{$main-text-font-size}"
> font-family="{$main-text-font}"
> hyphenate="true" language="en_US">
> <xsl:attribute name="id">
> <xsl:value-of select="concat( 'group-',text() )"/>
> </xsl:attribute>
> <xsl:apply-templates select="*"/>
> </fo:block-container>
> </xsl:template>
> <xsl:template name="header-h2">
> <xsl:param name="groupName"/>
> <xsl:call-template name="heading-rule"/>
> <fo:block font-size="18pt" space-before="12pt"
> keep-with-next="always"
> margin-left="{$headerOutdent}"
> hyphenate="false" language="en_US">
> <xsl:value-of select="$groupName"/>
> </fo:block>
> <xsl:call-template name="heading-rule">
> <xsl:with-param name="alignment">before-edge</xsl:with-param>
> </xsl:call-template>
> </xsl:template>
>
>
> On 03/23/2011 09:02 AM, Rob Sargent wrote:
>> Hello again Vincent,
>>
>> Thanks for looking into this. Presumptuous of me to think the fo would
>> be sufficient.
>>
>> I'll try some colouring experiments to verify but I'm nearly certain
>> there is plenty of room for the two lines. It's a two column layout and
>> there is several lines of text in the left column at the same position
>> we expect these to errant lines will go in the right column.
>>
>> I'm not sure how best to get my environment to you: Just to view the
>> problem, the pdf (2.5Mb) might be best? I am indeed using a couple of
>> non-standard fonts. I could tar up the source xml, stylesheet, fonts and
>> images (5Mb) if your game for that. Probably use yousendit.
>>
>> Pick your poison. :)
>>
>> It would also be possible for me to run inside an ide, if there are any
>> specific spots you can identify for me to "stop and look around".
>>
>> rjs
>>
>>
>>
>> On 03/23/2011 05:11 AM, Vincent Hennebert wrote:
>>> Hi Rob,
>>>
>>> I can’t reproduce your problem. In my version the mentioned paragraph
>>> ends up in the middle of the 2nd column of page 14. That’s probably
>>> because I don’t have the fonts you are using in your documents, and
>>> maybe neither the images.
>>>
>>> I’d say that this is due to the widows property whose value is 2 by
>>> default. Maybe in your version there is space for only one line, which
>>> would result in a widow line on the 2nd column (the last line of the
>>> paragraph ending up alone at the top of column 2). To avoid that FOP
>>> pushes the last two lines to the next column.
>>>
>>> Try setting a background colour on the region-body to better see its
>>> boundaries, and confirm that there is space only for one line.
>>>
>>> Otherwise, maybe you can send me your fonts offline and I’ll try to
>>> reproduce your version.
>>>
>>> HTH,
>>> Vincent
>>>
>>>
>>> On 18/03/11 23:34, Rob Sargent wrote:
>>>> Two lines of text are unnecessarily being delayed to the following
>>>> page/column, presumably being dragged along with the following
>>>> heading which
>>>> does not fit at the bottom of the preceding column? The heading
>>>> itself does
>>>> have keep-with-next, but not the fractured paragraph.
>>>>
>>>> In the attached fo, the example can be found across the boundaries of
>>>> pages
>>>> 14, 15 (on 8.5 X 11 paper). The following chunk gets split leaving
>>>> the text
>>>> from 'ings are nonspecific' onward on the following page.
>>>>
>>>> <fo:block text-align="justify" space-before="6pt">Intracranial MEs
>>>> are extremely rare but have been reported in the ventricles and
>>>> brain parenchyma. Imaging findings are nonspecific but are
>>>> generally those of a cyst with enhancing nodule.</fo:block>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: what might be forcing an early page/column break
Posted by Rob Sargent <rs...@xmission.com>.
"Some investigation" I suspect best translates as "hours of debugging
frustration dealing with an obtuse xsl-fo incarnation".
I for one am very thankful.
rjs
On 04/01/2011 07:36 AM, Vincent Hennebert wrote:
> Rob sent me his document offline and after some investigation
> I identified the issue: this is due to the keep-with-next property set
> on the last block of the document (and possibly its descendants). If you
> remove them then the document renders normally. They are unnecessary
> anyway, although I understand that this will complicate the XSLT part.
>
> Why on Earth does the keep on the last block have an influence on
> earlier elements? This is because of the infamous ‘Changing IPD hack’
> i.e., support for pages of different widths. Whenever a change of page
> width is detected, the remaining content is re-processed and it appears
> that some things are not properly reset.
>
> I’ll try and implement a fix soon. Meanwhile, the workaround I suggested
> above might do.
>
>
> HTH,
> Vincent
>
>
> On 23/03/11 15:40, Rob Sargent wrote:
>> I suspect your basic premise, widow control, is correct. I've added enough
>> text to the paragraph to force the original widow back on the the preceding
>> paragraph. And there is still more room in the preceding column (4 lines
>> worth, according to the column to the left) but I still get "two lines worth"
>> placed on the following column.
>>
>> Could there be some implicit attachment of the block (or surrounding
>> block-container) to the following heading? or the definition of the heading?
>>
>> I've attached the stylesheet (not the most straight forward xsl ever, I admit)
>> but the pertinent parts are here.
>>
>>>>>>> This block-container wraps a series of "paragraphs"
>> <xsl:template match="//preamble" priority="2">
>> <xsl:choose>
>> <xsl:when test="@ff_level='ff1'">
>> <xsl:call-template name="build-toc"/>
>> <fo:block-container font-family="{$preamble1-font}"
>> font-size="{$preamble1-font-size}" space-before="12pt" padding-after="18pt"
>> hyphenate="true" language="en_US">
>> <xsl:apply-templates select="*"/>
>> </fo:block-container>
>> </xsl:when>
>> <xsl:otherwise>
>> <fo:block font-family="{$main-text-font}"
>> font-size="{$main-text-font-size}" font-weight="normal">
>> <xsl:apply-templates select="*[name(.) !=
>> 'related-references']"/>
>> </fo:block>
>> </xsl:otherwise>
>> </xsl:choose>
>> </xsl:template>
>>
>>>>>>> This defines a "paragraph":
>> <xsl:template match="//paragraph" priority="2">
>> <fo:block space-before="{$pre-para-space}" text-align="{$right-edge}">
>> <xsl:value-of select="text()"/>
>> <xsl:call-template name="handle-references">
>> <xsl:with-param name="current" select="."/>
>> </xsl:call-template>
>> </fo:block>
>> </xsl:template>
>>
>>>>>>> And this is the heading which follows.
>> <xsl:template match="//dx-group">
>> <xsl:call-template name="header-h2">
>> <xsl:with-param name="groupName" select="text()"/>
>> </xsl:call-template>
>> <fo:block-container font-size="{$main-text-font-size}"
>> font-family="{$main-text-font}"
>> hyphenate="true" language="en_US">
>> <xsl:attribute name="id">
>> <xsl:value-of select="concat( 'group-',text() )"/>
>> </xsl:attribute>
>> <xsl:apply-templates select="*"/>
>> </fo:block-container>
>> </xsl:template>
>> <xsl:template name="header-h2">
>> <xsl:param name="groupName"/>
>> <xsl:call-template name="heading-rule"/>
>> <fo:block font-size="18pt" space-before="12pt"
>> keep-with-next="always"
>> margin-left="{$headerOutdent}"
>> hyphenate="false" language="en_US">
>> <xsl:value-of select="$groupName"/>
>> </fo:block>
>> <xsl:call-template name="heading-rule">
>> <xsl:with-param name="alignment">before-edge</xsl:with-param>
>> </xsl:call-template>
>> </xsl:template>
>>
>>
>> On 03/23/2011 09:02 AM, Rob Sargent wrote:
>>> Hello again Vincent,
>>>
>>> Thanks for looking into this. Presumptuous of me to think the fo would
>>> be sufficient.
>>>
>>> I'll try some colouring experiments to verify but I'm nearly certain
>>> there is plenty of room for the two lines. It's a two column layout and
>>> there is several lines of text in the left column at the same position
>>> we expect these to errant lines will go in the right column.
>>>
>>> I'm not sure how best to get my environment to you: Just to view the
>>> problem, the pdf (2.5Mb) might be best? I am indeed using a couple of
>>> non-standard fonts. I could tar up the source xml, stylesheet, fonts and
>>> images (5Mb) if your game for that. Probably use yousendit.
>>>
>>> Pick your poison. :)
>>>
>>> It would also be possible for me to run inside an ide, if there are any
>>> specific spots you can identify for me to "stop and look around".
>>>
>>> rjs
>>>
>>>
>>>
>>> On 03/23/2011 05:11 AM, Vincent Hennebert wrote:
>>>> Hi Rob,
>>>>
>>>> I can’t reproduce your problem. In my version the mentioned paragraph
>>>> ends up in the middle of the 2nd column of page 14. That’s probably
>>>> because I don’t have the fonts you are using in your documents, and
>>>> maybe neither the images.
>>>>
>>>> I’d say that this is due to the widows property whose value is 2 by
>>>> default. Maybe in your version there is space for only one line, which
>>>> would result in a widow line on the 2nd column (the last line of the
>>>> paragraph ending up alone at the top of column 2). To avoid that FOP
>>>> pushes the last two lines to the next column.
>>>>
>>>> Try setting a background colour on the region-body to better see its
>>>> boundaries, and confirm that there is space only for one line.
>>>>
>>>> Otherwise, maybe you can send me your fonts offline and I’ll try to
>>>> reproduce your version.
>>>>
>>>> HTH,
>>>> Vincent
>>>>
>>>>
>>>> On 18/03/11 23:34, Rob Sargent wrote:
>>>>> Two lines of text are unnecessarily being delayed to the following
>>>>> page/column, presumably being dragged along with the following
>>>>> heading which
>>>>> does not fit at the bottom of the preceding column? The heading
>>>>> itself does
>>>>> have keep-with-next, but not the fractured paragraph.
>>>>>
>>>>> In the attached fo, the example can be found across the boundaries of
>>>>> pages
>>>>> 14, 15 (on 8.5 X 11 paper). The following chunk gets split leaving
>>>>> the text
>>>>> from 'ings are nonspecific' onward on the following page.
>>>>>
>>>>> <fo:block text-align="justify" space-before="6pt">Intracranial MEs
>>>>> are extremely rare but have been reported in the ventricles and
>>>>> brain parenchyma. Imaging findings are nonspecific but are
>>>>> generally those of a cyst with enhancing nodule.</fo:block>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>>>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org