[
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582223#comment-14582223
]
Andreas L. Delmelle edited comment on FOP-2469 at 6/11/15 6:52 PM:
-------------------------------------------------------------------
I finally had a much closer look at the patch yesterday and today, attempting
to merge it into my local branch -- so far, so good, although the test file did
throw an Exception at one point. This is likely related to changes I have on my
end, so no worries there, but...
Looking at the stack trace, I have run into another minor thing that bothered
me slightly, design-wise: more imports from the o.a.f.layoutmgr package in the
o.a.f.fo.flow package. That said, there were already some there... References
the other way around bother me less, somehow. Perhaps more a matter of personal
taste.
As a resolution (for me, at least), I have moved the body of that method
getNextKEFromPrimary() into the
TableContentLayoutManager.determineWidthOfPrimaryGridUnit(), since it is the
only place where it is called from, and I do not immediately see anything in
said method that cannot be handled within the context of the layoutmgr package
( ? )
Perhaps that whole PGU class should move to the LM side, but that is a
different story -- and a lot more work, so not right now... ;)
OK, at least that stack trace looks a bit -- prettier. All calls in
o.a.f.layoutmgr...
{code}
java.lang.IllegalArgumentException: min (27840) > opt (27180)
at org.apache.fop.traits.MinOptMax.getInstance(MinOptMax.java:59)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.setBaseLength( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineWidthOfPrimary(
)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.iterateOverTableRows( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineAutoLayoutWidths(
)
at
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements( )
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
...
{code}
Now, on with the hunt for the cause of that Exception! :)
EDIT - Actually, it may be something worth looking into on your end as well.
The block of code where the Exception is thrown seems to assert that ipd will
always be larger than minIPD ( ? )
See below, line 3.
{code:language=java|title=TableContentLayoutManager.getBaseLength()}
if (index == n - 1) { // a primary without col-span > 1
if ((availableSpanWidth < ipd) || (length.getMin() < minIPD)) { // cell
needs more space
assert (ipd > minIPD);
MinOptMax possibleWidths =
MinOptMax.getInstance(
Math.max(length.getMin(), minIPD),
Math.max(length.getOpt(), ipd),
Math.max(length.getMax(), ipd)
);
return length == this.baseLength.put(key, possibleWidths);
{code}
was (Author: adelmelle):
I finally had a much closer look at the patch yesterday and today, attempting
to merge it into my local branch -- so far, so good, although the test file did
throw an Exception at one point. This is likely related to changes I have on my
end, so no worries there, but...
Looking at the stack trace, I have run into another minor thing that bothered
me slightly, design-wise: more imports from the o.a.f.layoutmgr package in the
o.a.f.fo.flow package. That said, there were already some there... References
the other way around bother me less, somehow. Perhaps more a matter of personal
taste.
As a resolution (for me, at least), I have moved the body of that method
getNextKEFromPrimary() into the
TableContentLayoutManager.determineWidthOfPrimaryGridUnit(), since it is the
only place where it is called from, and I do not immediately see anything in
said method that cannot be handled within the context of the layoutmgr package
( ? )
Perhaps that whole PGU class should move to the LM side, but that is a
different story -- and a lot more work, so not right now... ;)
OK, at least that stack trace looks a bit -- prettier. All calls in
o.a.f.layoutmgr...
{code}
java.lang.IllegalArgumentException: min (27840) > opt (27180)
at org.apache.fop.traits.MinOptMax.getInstance(MinOptMax.java:59)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.setBaseLength( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineWidthOfPrimary(
)
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.iterateOverTableRows( )
at
org.apache.fop.layoutmgr.table.TableContentLayoutManager.determineAutoLayoutWidths(
)
at
org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextChildElements( )
at
org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements( )
...
{code}
Now, on with the hunt for the cause of that Exception! :)
> [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
>
>
> 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)
