[
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588646#comment-14588646
]
Gregor Berg commented on FOP-2469:
----------------------------------
In the width determination, having one table is quite simple and
straight-forward: collect minIPD and IPD and, if the sum of IPDs is greater
than the available space: redistribute until each column has an individual
optimal value opt for which holds: minIPD<=opt<=IPD (for each column's
respective pair of minIPD and IPD!).
In case we have to deal with nested tables, things get much more complicated
mainly due to the fact that we cannot know the minIPD of the 'outside' table
without determining the minIPD of the 'inside' table (which is the sum of all
column's minIPD + indentations). If, e.g., the outer table is fixed, has a
width of 100pt and two columns, both columns would have a 'hard refIPD' of
50pt, which is set for all the outer table's TableCellLMs. If another table,
which has a minIPD of 51pt, is contained in one of these table cells an
overflow will occur since FOP cannot shrink the inner table any more.
HOWEVER, if the outer table itself is contained in a table with auto-layout,
its 'hard refIPF' is subject to change depending on how wide the column of the
auto table will be. In these cases, the innermost table's minIPD is set as
minIPD of the middle/fixed table's TableCellLM, which in turn may influence the
minIPD of the outer auto table. Essentially, FOP needs to derive appropriate
minIPD values for all containers - while it starts from the top, FOP has to
drill down into each atomic unit and, if one of its parents uses auto-layout,
propagate its minIPD bottom-up.
During this process, ipd values may be smaller than minIPD values - this should
be handled by increasing the ipd value which, in turn, is propagated via
context.setRefIPD():
{code:title=TableLayoutManager.getNextKnuthElements()|borderStyle=solid}
referenceIPD = context.getRefIPD();
// ...
final int ipd = childLC.getRefIPD();
if (currentChildLM instanceof LineLayoutManager) {
if (getContentAreaIPD() < ipd && (isAutoLayout() ||
context.isChildOfAutoLayoutElement())) {
this.referenceIPD = this.startIndent + ipd + this.endIndent;
updateContentAreaIPDwithOverconstrainedAdjust();
context.setRefIPD(this.referenceIPD);
}
} else if (this.referenceIPD < ipd && (isAutoLayout() ||
context.isChildOfAutoLayoutElement())) {
this.referenceIPD = ipd;
updateContentAreaIPDwithOverconstrainedAdjust();
context.setRefIPD(this.referenceIPD);
}
{code}
So, while it should not occur, it is technically possible that a PGU's
TableCellLM has an ipd which is less than its minIPD.
*Possible cause are:* the TableCellLM's ipd was not increased after the
TableCellLM's content was determined to require more space _or_ the PGU's
minIPD was calculated incorrectly.
The latter happened for me which is why you can find this crude correction as
well:
{code:title=TableLayoutManager.setBaseLength()|borderStyle=solid}
if ((availableSpanWidth == 0) || (length == null)) {
// TODO: remove the following IF as soon as the computation of minIPD is
corrected
if (minIPD > ipd) { // happens e.g. for cells containing a space: ipd=0,
minIPD=len(" ")
ipd = minIPD;
} // ...
}
{code}
Looking at this assignment and the _if_ clause above - it may also be the case
that your code bypasses this first assignment and goes straight to _else_. In
this case, it may be worth a try to put this corrective assignment even before
the first _if_ to ensure that the minIPD value (the least amount of space this
LM needs) is the one which FOP propagates to from this LM upwards.
I hope this helps to solve the problem.
> [PATCH] auto table layout
> -------------------------
>
> Key: FOP-2469
> URL: https://issues.apache.org/jira/browse/FOP-2469
> Project: FOP
> Issue Type: Bug
> Components: layout/unqualified
> Affects Versions: trunk
> Environment: Windows 7, JDK 7
> Reporter: Gregor Berg
> Assignee: Andreas L. Delmelle
> Fix For: trunk
>
> Attachments: 2015-05-13-auto-table-layout.patch,
> 2015-05-27-LM-to-LC-refactoring.patch,
> 2015-06-09-LM-to-LC-refactoring-update.patch, FOP2469-auto-table-layout.xml,
> LayoutContext_Tweak.diff, resize-all-but-static-spanned-columns.xml,
> resize-spanned-columns.xml, warning-only-static-columns-are-spanned.xml
>
>
> Hi,
> this is a patch which enables table-layout=auto. It is quite robust, it can
> not only handle linebreaks and pagebreaks, but it also copes with auto tables
> in fixed tables in auto tables.
> Essentially, it is the patch of issue FOP-2450 adapted to the trunk version
> of FOP.
> Best regards,
> Gregor
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
