[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14560986#comment-14560986 ] Gregor Berg commented on FOP-2469: -- I tried to pass the information (whether the current LM is contained in an element using automatic layout and whether the current invocation is part of the preprocessing step) *down* using LayoutContexts (LCs). What I found is: * I had to propagate the two corresponding booleans at least 5 times to a new childLC (= LayoutContext.newInstance()) ** if this propagation is skipped/forgotten at any point in the LC chain, the results are catastrophic ** since any LM should be able to contain any other LM, each LM's individual version of creating a new LC (e.g. BlockStackingLM's makeChildLayoutContext(LC)) needs to be adapted to *always* propagate these two new values * in the current version of the patch, most decisions of how to continue or which value to return are based on the LM and its bottom-up lookup instead of the LC ** the LM is almost always explicitly accessible, while the LC neets to be passed down (up to 5 times, through stacks of other methods) into individual methods were the decision is made While I think that the second point might be solved through refactoring, changing the way LCs are initialized throughout FOP (first point) may not be feasible for this context. A patch file illustrating such a refactoring (2015-05-27-LM-to-LC-refactoring.patch: covers some cases, others will produce incorrect results) will be attached shortly - it will show how much additional effort would have to go into LC initialization. [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)
[jira] [Updated] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregor Berg updated FOP-2469: - Attachment: 2015-05-27-LM-to-LC-refactoring.patch illustration of how a switch from LM bottom-up (O(n)) to LC top-down (O(1)) might look like [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, 2015-05-27-LM-to-LC-refactoring.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)
Re: Q - Internal API preference? (It started with a 'simple' TODO...)
On 27 May 2015, at 01:59, Luis Bernardo lmpmberna...@gmail.com wrote: Hi Luis In my view any code that does more becomes more complex, not less comprehensible. The same happens with FOP. Very true, indeed. I recall having argued that same point on this list in the past. Doing more with less is, IMO, executive lingo that is almost always meant to hide some uglier truths... ;) It is more a matter of making sure that new code that gets added will follow the right path, if you will (whatever that may mean). No criticism there. After all, I *was* part of the team for years, so know full well to what extent time and resource constraints have influenced some of those decisions. If you want to rewrite the layout engine and do it with less code then go for it. You will get a +1 from me. OK, good to know. Just to be clear: it is not so much a 'rewrite' as it is optimising or streamlining what is already there, and it remains to be seen whether it will literally lead to 'less' code, since it would require introduction of a few new interfaces/classes. Overall, I would expect the total LOC to go up, slightly, but I have not yet finished so cannot say anything for sure there at this point. Thanks! KR Andreas
[jira] [Assigned] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle reassigned FOP-2469: Assignee: Andreas L. Delmelle [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, 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)
Re: [jira] [Updated] (FOP-2469) [PATCH] auto table layout
Hi Gregor Just a heads-up, if you're reading this: We (I) have not forgotten. :) Will probably have more time next week to have a closer look at your work. Thanks for updating the Wiki, BTW. That stuff is very valuable info! KR Andreas On 27 May 2015, at 15:51, Gregor Berg (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregor Berg updated FOP-2469: - Attachment: 2015-05-27-LM-to-LC-refactoring.patch illustration of how a switch from LM bottom-up (O(n)) to LC top-down (O(1)) might look like [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, 2015-05-27-LM-to-LC-refactoring.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)
Re: Q - Internal API preference? (It started with a 'simple' TODO...)
One significant risk in a major rewrite of an important section is regression. This is particularly true given the paucity of tests in FOP. You will have to assume that such a rewrite is going to produce a number of regressions (while continuing to pass the test suite). On Wed, May 27, 2015 at 9:45 AM, Andreas Delmelle andreas.delme...@telenet.be wrote: On 27 May 2015, at 01:59, Luis Bernardo lmpmberna...@gmail.com wrote: Hi Luis In my view any code that does more becomes more complex, not less comprehensible. The same happens with FOP. Very true, indeed. I recall having argued that same point on this list in the past. Doing more with less is, IMO, executive lingo that is almost always meant to hide some uglier truths... ;) It is more a matter of making sure that new code that gets added will follow the right path, if you will (whatever that may mean). No criticism there. After all, I *was* part of the team for years, so know full well to what extent time and resource constraints have influenced some of those decisions. If you want to rewrite the layout engine and do it with less code then go for it. You will get a +1 from me. OK, good to know. Just to be clear: it is not so much a 'rewrite' as it is optimising or streamlining what is already there, and it remains to be seen whether it will literally lead to 'less' code, since it would require introduction of a few new interfaces/classes. Overall, I would expect the total LOC to go up, slightly, but I have not yet finished so cannot say anything for sure there at this point. Thanks! KR Andreas
Re: Q - Internal API preference? (It started with a 'simple' TODO...)
Hi Glenn On 27 May 2015, at 18:36, Glenn Adams gl...@skynav.com wrote: One significant risk in a major rewrite of an important section is regression. This is particularly true given the paucity of tests in FOP. You will have to assume that such a rewrite is going to produce a number of regressions (while continuing to pass the test suite). Yep, also very true... To reduce that risk, it is likely best to follow up on the idea of creating that branch first, and give others a chance to have a look and run some local tests for a couple of months before merging it back after a proper vote. After all, I am not so presumptuous as to consider myself infallible. As I recall, one other significant change I worked on locally, way back when, got committed to trunk directly and, benefits aside, turned out to cause quite some issues in production environments later on, after a major release, mainly due to insufficient regression testing (PropertyCache, anyone? :/) Rest assured that I will not make that same mistake twice. Thanks! KR Andreas
[jira] [Issue Comment Deleted] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas L. Delmelle updated FOP-2469: - Comment: was deleted (was: 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.) [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, 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)
Re: [jira] [Issue Comment Deleted] (FOP-2469) [PATCH] auto table layout
FYI - Comment actually had nothing to do with the patch, so decided to remove it, so as to not let Gregor's fine work drown in unrelated ranting... On 27 May 2015, at 21:07, Andreas L. Delmelle (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] snip / -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: FOP - POI
On 2015-05-25 Andreas Delmelle wrote: On 2015-05-25 Jan Tosovsky wrote: can you hypothetically imagine any way how to convert virtual page objects to the office document structure? I actually I think of 'Slides' to PPTX (XSLF) conversion. There is not an easy way to produce paginated PPTX content using pure XSLT. But FOP has all the required info somewhere in the memory before serializing it into PDF, which could be somehow pushed to POI. it seems like it may just be possible to achieve something like this by means of FOP's Intermediate Formats[*], which can already be utilised to split up the basic formatting and rendering processes. This approach could theoretically elimintate POI completely as most of IF - PPTX could be done via XSLT ;-) But it is too low level for me. Anyway, I'll investigate also POI end. Jan attachment: winmail.dat
Re: FOP - POI
Hi Jan, I know pptx a bit, because I had to implement an output channel based mainly on XSLT and a little bit of java (used mainly for zip compression). Pptx is hard to understand because of all the cross references between the different files, but that wouldn't justify to add another dependency to FOP. So +1 for adding a pptx output to FOP, but I'd recommend doing it without POI. BR, Matthias On 27.05.2015 17:26, Jan Tosovsky wrote: Hi Andreas, On 2015-05-27 Andreas Delmelle wrote: On 2015-05-27 Jan Tosovsky wrote: On 2015-05-25 Andreas Delmelle wrote: snip / it seems like it may just be possible to achieve something like this by means of FOP's Intermediate Formats[*], which can already be utilised to split up the basic formatting and rendering processes. This approach could theoretically elimintate POI completely as most of IF - PPTX could be done via XSLT ;-) But it is too low level for me. Can you clarify? Not sure I am completely following here... Is POI *not* low level, then? I meant PPTX side, mainly various 'dictionaries'. When e.g. a new slide is added, its ID is registered in the main file. The slide is derived from a default template, which must be linked via its ID. Slides can have annotations, there is also a special template for them, it has to be linked to the slide as well, and so on... This cross referencing in POI is out of the box. You just add a new slide and all references are updated automatically. Yes, it is doable in pure XSLT, but with additional effort. Another thing is bulding the final PPTX file. What you rather vaguely describe as the required info somewhere in the memory before serializing it into PDF for FOP basically *is* the Area Tree. The AT and IF XML formats are just XML representations of said info, so seems like you would not get around it either way...? I simply didn't know that. Thanks for explanation, Jan
RE: FOP - POI
Hi Andreas, On 2015-05-27 Andreas Delmelle wrote: On 2015-05-27 Jan Tosovsky wrote: On 2015-05-25 Andreas Delmelle wrote: snip / it seems like it may just be possible to achieve something like this by means of FOP's Intermediate Formats[*], which can already be utilised to split up the basic formatting and rendering processes. This approach could theoretically elimintate POI completely as most of IF - PPTX could be done via XSLT ;-) But it is too low level for me. Can you clarify? Not sure I am completely following here... Is POI *not* low level, then? I meant PPTX side, mainly various 'dictionaries'. When e.g. a new slide is added, its ID is registered in the main file. The slide is derived from a default template, which must be linked via its ID. Slides can have annotations, there is also a special template for them, it has to be linked to the slide as well, and so on... This cross referencing in POI is out of the box. You just add a new slide and all references are updated automatically. Yes, it is doable in pure XSLT, but with additional effort. Another thing is bulding the final PPTX file. What you rather vaguely describe as the required info somewhere in the memory before serializing it into PDF for FOP basically *is* the Area Tree. The AT and IF XML formats are just XML representations of said info, so seems like you would not get around it either way...? I simply didn't know that. Thanks for explanation, Jan
[jira] [Commented] (FOP-2469) [PATCH] auto table layout
[ https://issues.apache.org/jira/browse/FOP-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14560501#comment-14560501 ] Gregor Berg commented on FOP-2469: -- I finished some documentation over the last week and already got sidetracked into some changes I'm currently working on. Anyway, the documentation (of the current version of the patch) is available under https://wiki.apache.org/xmlgraphics-fop/AutoTableLayout. [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)
