[jira] [Comment Edited] (FOP-2469) [PATCH] Auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598596#comment-16598596 ] simon steiner edited comment on FOP-2469 at 8/31/18 11:10 AM: -- Table footer has newline after this patch, see test.fo file, also checkstyle fails was (Author: ssteiner1): Table footer has newline after this patch, see test.fo file > [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 >Priority: Major > 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, FOP-2469-2018-07-17.patch, > FOP-2469_20150621.patch, FOP2469-auto-table-layout.xml, > resize-all-but-static-spanned-columns.xml, resize-spanned-columns.xml, > test.fo, 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 (v7.6.3#76005)
[jira] [Comment Edited] (FOP-2469) [PATCH] auto table layout
[
https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Comment Edited] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14551034#comment-14551034 ] Andreas L. Delmelle edited comment on FOP-2469 at 5/19/15 7:21 PM: --- Side-note - Reading that (rather old) Wiki page again, with Jeremias' brain-dump (his words, not mine ;)), it just so happens that in my local sandbox, I am currently toying with that split in line-layout he is referring to. The problem Jeremias mentions has led to an implementation for changing page IPD that is actually suboptimal. No complaints on those who did the implementation, mind you. It is actually quite a feat that that someone managed to implement it in the first place. R-E-S-P-E-C-T! :) However, as a result, if you have a page-sequence with alternating page-masters with different margins, then (assuming no forced breaks) due to the fact that line-breaking is not really interrupted, the process will go roughly as: - perform line-breaking for all 40 pages - start page-breaking, and notice that available IPD changes after the first page - throw away every computed break after that first page, and restart from the second - perform line-breaking for 39 pages - start page-breaking, and notice that available IPD changes after the second page - throw away ... and restart from the third page - perform line-breaking for 38 pages etc. Now, the LayoutContext _does_ have the stack limit in BP direction available, so at least, it _should_ be possible for the LineLM to determine that after a certain number of line-breaks, there will inevitably be a page-break... If at that point, we could make the engine behave as if there was a forced break or something like that, then it could suspend, switch to page-breaking context, compute that one page-break, obtain the dimensions for the next page, and resume. I have always found it peculiar that the stackLimitBP is available, but is never really taken advantage of. was (Author: adelmelle): Side-note - Reading that (rather old) Wiki page again, with Jeremias' brain-dump (his words, not mine ;)), it just so happens that in my local sandbox, I am currently toying with that split in line-layout he is referring to. The problem Jeremias mentions has led to an implementation for changing page IPD that is actually suboptimal. No complaints on those who did the implementation, mind you. It is actually quite a feat that that someone managed to implement it in the first place. R-E-S-P-E-C-T! :) However, as a result, if you have a page-sequence with alternating page-masters with different margins, then (assuming no forced breaks) due to the fact that line-breaking is not really interrupted, the process will go roughly as: - perform line-breaking for all 40 pages - start page-breaking, and notice that available IPD changes after the first page - throw away every computed break after that first page, and restart from the second - perform line-breaking for 39 pages - start page-breaking, and notice that available IPD changes after the second page - throw away ... and restart from the third page - perform line-breaking for 38 pages etc. [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 Fix For: trunk Attachments: 2015-05-13-auto-table-layout.patch, FOP2469-auto-table-layout.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)
