|Summary:||[PATCH] fo:inline-container implementation|
|Product:||Fop - Now in Jira||Reporter:||Andreas L. Delmelle <adelmelle>|
patch for the implementation
Small test FO
PDF result after applying the patch
Updated patch: added support for display-align and ipd="auto"
Updated sample FO
Updated sample PDF result
Updated sample FO: added some examples for alignment-adjust
Updated sample PDF result
updated patch against latest trunk
Description Andreas L. Delmelle 2008-04-27 17:03:06 UTC
Created attachment 21861 [details] patch for the implementation This Bugzilla entry will be used for the moment to keep track of the progress of an implementation for fo:inline-container. The related changes are restricted to a handful of classes, so branching seemed like overkill. No commits to the trunk yet, since I see some possible overlap with Simon's branch. Anyway, status so far. The rough patch in attachment models the InlineContainerLayoutManager along the lines of BlockContainerLayoutManager. It already aligns the content better than my last attempt (way back when). Still some things remaining to check out, but the basics are there...
Comment 1 Andreas L. Delmelle 2008-04-27 17:05:04 UTC
Created attachment 21862 [details] Small test FO
Comment 2 Andreas L. Delmelle 2008-04-27 17:07:54 UTC
Created attachment 21863 [details] PDF result after applying the patch
Comment 3 Andreas L. Delmelle 2008-05-01 05:58:58 UTC
Created attachment 21893 [details] Updated patch: added support for display-align and ipd="auto"
Comment 4 Andreas L. Delmelle 2008-05-01 06:00:01 UTC
Created attachment 21894 [details] Updated sample FO
Comment 5 Andreas L. Delmelle 2008-05-01 06:00:53 UTC
Created attachment 21895 [details] Updated sample PDF result
Comment 6 Andreas L. Delmelle 2008-05-01 07:03:56 UTC
Still to do after the patch in attachment #21893 [details]: - add support for reference-orientation: started off by adding a CTM to area.inline.Viewport; modifications to AbstractRenderer still needed to make use of it (see test output: the grey inline-container on page 2 should have its content rotated by 180 degrees) - check area-alignment properties
Comment 7 Andreas L. Delmelle 2008-05-01 07:07:35 UTC
Created attachment 21896 [details] Updated sample FO: added some examples for alignment-adjust
Comment 8 Andreas L. Delmelle 2008-05-01 07:09:34 UTC
Created attachment 21897 [details] Updated sample PDF result
Comment 9 Andreas L. Delmelle 2011-02-10 18:21:04 UTC
Created attachment 26636 [details] updated patch against latest trunk New rough patch. Only confirmed that it renders the attached sample exactly the same as before. Layout unit tests all seem to be unaffected, as expected. Some checkstyle issues, I know. Definitely still far too sketchy and also generates too much overhead. I already factored out the inner breaker (which can then be shared with BlockContainerBreaker), but still... The nested/deferred algorithm should probably not be a full PageBreakingAlgorithm, and the breaker itself should provide straightforward/simplified overrides of more methods to control that BreakingAlgorithm.
Comment 10 Matthias Reischenbacher 2011-04-19 16:54:19 UTC
Thanks for your patch, Andreas! One question... > New rough patch. Only confirmed that it renders the attached sample exactly the > same as before. Layout unit tests all seem to be unaffected, as expected. Some > checkstyle issues, I know. Definitely still far too sketchy and also generates > too much overhead. Is this overhead also present if inline-container elements are not used?
Comment 11 Andreas L. Delmelle 2011-04-19 17:43:39 UTC
(In reply to comment #10) > Thanks for your patch, Andreas! One question... > > > New rough patch. Only confirmed that it renders the attached sample exactly the > > same as before. Layout unit tests all seem to be unaffected, as expected. Some > > checkstyle issues, I know. Definitely still far too sketchy and also generates > > too much overhead. > > Is this overhead also present if inline-container elements are not used? That's a definite No. Only documents actually using fo:inline-container would be affected. The overhead I am referring to specifically, is the 'abuse' of PageBreakingAlgorithm. While the approach makes sense for absolute-positioned or rotated block-containers --and may turn out to be unavoidable for similar inline-containers-, regular block-containers would generate less overhead than regular inline-containers, which seems wrong somehow...? I am worried that a document with, say 200 inline-containers would generate just as many PageBreakingAlgorithms, and those can hardly be considered light-weight objects. Those instances will take up valuable heap space, since they are all kept alive until the parent's addAreas() has been called...
Comment 12 Glenn Adams 2012-04-07 01:39:43 UTC
resetting P1 open bugs to P3 pending further review
Comment 13 Glenn Adams 2012-04-11 03:22:23 UTC
increase priority for bugs with a patch
Comment 14 Glenn Adams 2012-04-11 06:17:52 UTC
change status from ASSIGNED to NEW for consistency