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...
Created attachment 21862 [details] Small test FO
Created attachment 21863 [details] PDF result after applying the patch
Created attachment 21893 [details] Updated patch: added support for display-align and ipd="auto"
Created attachment 21894 [details] Updated sample FO
Created attachment 21895 [details] Updated sample PDF result
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
Created attachment 21896 [details] Updated sample FO: added some examples for alignment-adjust
Created attachment 21897 [details] Updated sample PDF result
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.
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?
(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...
resetting P1 open bugs to P3 pending further review
increase priority for bugs with a patch
change status from ASSIGNED to NEW for consistency