[ 
https://issues.apache.org/jira/browse/FOP-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14532875#comment-14532875
 ] 

Andreas L. Delmelle edited comment on FOP-1488 at 5/7/15 5:09 PM:
------------------------------------------------------------------

A very interesting question... 
If there is an image inserted, that would always be as an inline area, which is 
taken into account when calculating the height of the line area. 
Strictly speaking, I am inclined to say that from the spec point of view, it 
would indeed be non-compliant to treat images any differently than text or 
characters in this respect.

Having said that, the issue is actually a consequence of FOP being more 
compliant than before. It explains why I never simply committed the whole 
bunch, since it would be a rather significant change that quite some users may 
see as 'breaking' their existing cases. 
See also the patch with changes required to the layout tests... I think this 
definitely needs to be mentioned very, very clearly and prominently in the 
release documentation, to fend off a possible plethora of questions about this 
change in behaviour. 

Not sure if the workaround I used for some of the tests can be applied in your 
case, i.e. setting the orphans/widows values to "1" on the blocks in question 
would be sufficient to revert to the old behaviour. Both properties are 
inherited, so can be set on the root and will be inherited by all descendant 
blocks, in case it needs to apply to a whole document.

If the above is not feasible in those cases, I think the most appropriate way 
to accommodate that requirement would be through a config parameter or maybe an 
extension attribute.

Note: The latter is, I think, only necessary if the case is a really special 
mixture of text and images, and you rely on the engine to find the optimal 
breaks in that mixed content. If the content consists solely of images, your 
best bet is most likely just to use the standard, i.e. set both properties 
explicitly to "1" at the applicable level in the document to allow page-breaks 
between _any_ of the generated line boxes.


was (Author: adelmelle):
A very interesting question... 
If there is an image inserted, that would always be as an inline area, which is 
taken into account when calculating the height of the line area. 
Strictly speaking, I am inclined to say that from the spec point of view, it 
would indeed be non-compliant to treat images any differently than text or 
characters in this respect.

Having said that, the issue is actually a consequence of FOP being more 
compliant than before. It explains why I never simply committed the whole 
bunch, since it would be a rather significant change that quite some users may 
see as 'breaking' their existing cases. 
See also the patch with changes required to the layout tests... I think this 
definitely needs to be mentioned very, very clearly and prominently in the 
release documentation, to fend off a possible plethora of questions about this 
change in behaviour. 

Not sure if the workaround I used for some of the tests can be applied in your 
case, i.e. setting the orphans/widows values to "1" on the blocks in question 
would be sufficient to revert to the old behaviour. Both properties are 
inherited, so can be set on the root and will be inherited by all descendant 
blocks, in case it needs to apply to a whole document.

If the above is feasible in those cases, I think the most appropriate way to 
accommodate that requirement would be through a config parameter or maybe an 
extension attribute.

Note: The latter is, I think, only necessary if the case is a really special 
mixture of text and images, and you rely on the engine to find the optimal 
breaks in that mixed content. If the content consists solely of images, your 
best bet is most likely just to use the standard, i.e. set both properties 
explicitly to "1" at the applicable level in the document to allow page-breaks 
between _any_ of the generated line boxes.

> [PATCH] orphans/widows not respected in some cases
> --------------------------------------------------
>
>                 Key: FOP-1488
>                 URL: https://issues.apache.org/jira/browse/FOP-1488
>             Project: Fop
>          Issue Type: Bug
>          Components: unqualified
>    Affects Versions: trunk
>         Environment: Operating System: All
> Platform: All
>            Reporter: Andrew McFarland
>         Attachments: FOP-1488-code.patch, FOP-1488-test.patch, b44328.patch, 
> b44328.patch, b44328.patch, b44328.patch, b44328.patch, b44328.patch, 
> b44328.patch, b44328_test.patch, block_orphans_widows.fo, 
> block_orphans_widows.fo, block_orphans_widows.fo, block_orphans_widows.fo, 
> block_orphans_widows.fo, widow.fo
>
>
> When I process the following fo, I get a PDF with a one-line widow at the 
> start
> of the second page, even though widows for that fo:block is set to 4.
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format";>
> <fo:layout-master-set>
>   <fo:simple-page-master master-name="A4">
>     <fo:region-body />
>   </fo:simple-page-master>
> </fo:layout-master-set>
> <fo:page-sequence master-reference="A4">
>   <fo:flow flow-name="xsl-region-body">
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block>Paragraph</fo:block>
>     <fo:block widows="4" linefeed-treatment="preserve" >line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> line
> </fo:block>
>   </fo:flow>
> </fo:page-sequence>
> </fo:root>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to