https://issues.apache.org/bugzilla/show_bug.cgi?id=49687
--- Comment #34 from Andreas L. Delmelle <[email protected]> 2011-06-12 11:54:08 UTC --- (In reply to comment #31) > (In reply to comment #30) > > I had a brief look at your branch and have the following questions and > > comments: > > > > You implemented the BIDI algorithm in a separate BidiUtil class. Why didn't > > you > > integrate it into the layout engine? It seems that what is done there is a > > layout task, therefore should be put in the layout engine classes. FO tree > > objects are now manipulated by both the layout engine and that class, and > > I'm > > seriously concerned about the maintenance issues that that may create. > > BidiUtil is defined in o.a.f.layoutmgr, therefore it is "integrated into the > layout engine". I considered placing it in o.a.f.util or in o.a.f.text.bidi; > however, since it is only referenced by o.a.f.layoutmgr code, I decided that > was the best home for it at this time. Just to weigh in here: On the one hand, I believe that the layout *managers* should actually remain quite BIDI-agnostic. Ultimately, to a layout manager, it should only matter how wide/heigh a given text-fragment will be and how its own child areas should be stacked. In what direction text should be rendered, is hardly its concern. The TextLM, maybe... but that is already quite large. That said, Vincent's point is a valid one. The observation certainly does not mean that more LMs shouldn't *use* the BIDI functionality. Almost on the contrary... Thinking out loud, maybe a singleton that is made available in the top level LM would be more appropriate. That would allow potential optimizations, in that BIDI is then not applied to a page-sequence as a whole, but gradually, as layout progresses. > However, having said that, it is not performing layout and knows nothing about > areas or geometries whatsoever. It's functionality is invoked in two places: > > (1) in PageSequenceLayoutManager.activateLayout(), in order to resolve bidi > levels of each delimited text range, and > (2) in LineLayoutManager.add{Inline,Block}Area, after completing line area > construction; > > See XSL-FO Section 5.8 for more information. I'm open to any concrete > suggestions about a better point of integration, but I don't see any at > present > that is consistent with 5.8. I am even thinking that the first part (resolving embedding levels) can be handled entirely in the FO tree. Places like finalizeNode() come to mind. That way, RTF output (or more generally: formats not using the AreaTreeHandler and the layout engine) would also be able to benefit from it. Also, I notice 'blind' traversal of the ancestry of a node. 'Blind' means that I am wondering what happens with BIDI processing in retrieved fo:markers. The spec is not entirely clear about it, but given that writing-mode is involved, I would expect the behavior to be similar to property-resolution, where the base context comes from the parent of the fo:retrieve-marker, not the actual parent node in the source document. Integrating the step in the FO tree would make this relatively straightforward to solve. The first step would be skipped during initial parsing, and instead executed as part of the resolveRetrieveMarker() logic that is invoked during layout of static content. <snip /> > > How feasible is it to run the BIDI algorithm on a subset of the FO tree? If > > I'm > > right, ATM it is launched on a whole page-sequence. When we refactor the > > code > > so that layout can be started before a whole page-sequence has been parsed, > > in > > order to avoid the infamous memory issue that a lot of users are running > > into, > > will that code allow to do it? > > I'm not sure what you mean by "ATM". The semantics of XSL-FO 5.8 as embodied > by > the present implementation will have to be taken into account by such a > refactoring, as I'm sure will many other aspects of the current FOP > implementation. XSL-FO doesn't go so far as specifying that this all has to be applied to the page-sequence as a whole. That would be an implementation detail. As long as the result is compliant, it shouldn't matter whether, architecturally, we process complete page-sequences or separate blocks. I still firmly believe there is a possibility to switch from endPageSequence() to endBlock(). Only blocks that are direct children of a fo:flow should be used as logical boundaries to trigger layout (and, if possible, rendering) of all content up to that point. The proposed approach should work too, preferably without too much refactoring, as it would be the idea of purging all finished blocks. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
