Jason Harrop created FOP-3353:
---------------------------------
Summary: Since FOP-3331, text is no longer set beside a side float
whose child is an fo:block-container
Key: FOP-3353
URL: https://issues.apache.org/jira/browse/FOP-3353
Project: FOP
Issue Type: Bug
Components: layout/page
Affects Versions: main
Reporter: Jason Harrop
FOP-3331 (commit 744281b1e, "Fix incorrect text positioning when using a
float") added a branch to FloatContentLayoutManager.addChildArea: when
getEffectiveAllocIPD(childArea) >= childArea.getIPD(), the float is added in
the flow (addAreaInFlow), and the content after it goes below it at full width.
When an fo:block-container is the float's own child, childArea is the
container's BlockViewport. Its IPD is the container's width, and
getEffectiveAllocIPD returns that same width: it does not descend into a
BlockViewport, and BlockViewport.getEffectiveIPD() is getIPD(). So the test
compares the container's width with itself and always holds, and every such
float is placed in the flow, however narrow it is. A float whose content is a
plain fo:block is unaffected, since its area has the width available to the
float.
Minimal FO (A4, 72pt margins, Times 12pt):
{noformat}
<fo:block line-height="16pt" space-after="10pt"><fo:float
float="left"><fo:block-container width="100pt"
height="20pt"><fo:block
font-size="10pt">box</fo:block></fo:block-container></fo:float>Heading</fo:block>
<fo:block line-height="16pt">word0 word1 ... word29</fo:block>
{noformat}
Where "Heading" is drawn (pdftotext -bbox, the word's top left):
||float content||b4d2c3d0b (before)||744281b1e (FOP-3331)||main 5be8c69b6||
|block-container 100pt, text inside|x 172, y 74.6|x 72, y 94.6|x 72, y 94.6|
|block-container 300pt, empty block|x 372, y 74.6|x 72, y 94.6|x 72, y 94.6|
|fo:block, text (no block-container)|x 104.5, y 74.6|x 104.5, y 74.6|x 104.5, y
74.6|
|fo:block > block-container 100pt|x 172, y 74.6|x 172, y 74.6|x 172, y 74.6|
|fo:block > table 100pt|x 172, y 74.6|x 172, y 74.6|x 172, y 74.6|
Before FOP-3331 the heading is set beside the float (x 172 beside the 100pt
container); since, it is set below the float at full width (y 94.6, under the
float's 20pt), as if the container filled the column. A container wrapped in an
fo:block inside the float is unaffected (the last two rows), since the area
tested is then the block's, with the width available to the float; wrapping is
a workaround until this is fixed.
The test FOP-3331 meant, by its comment, is whether the float's content is as
wide as the space it could take. That is the containing block's width, not the
float content's own area's. Comparing against the width available to the float
(for instance the IPD of the reference area addChildArea already walks up to),
or not taking the in-flow path for a BlockViewport child whose IPD was set by
its width property, would keep FOP-3331's case and restore this one. I have not
written or tested a change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
