https://issues.apache.org/bugzilla/show_bug.cgi?id=49687
--- Comment #35 from Glenn Adams <gl...@skynav.com> 2011-06-12 13:28:35 UTC ---
(In reply to comment #34)
> (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.
One point where LMs are exposed to bidi is that the rendering system assumes a
left to right rendering direction of areas irrespective of bidi, while
start/end edges vary according to bidi context.
For example, the start/end indent traits on generated areas varies with bidi
levels. Also, certain progression directions, such as table column progression,
list label versus list body, region start versus region end, etc., all vary by
bidi level. In some cases this variation must be accounted for in an LM.
> 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.
It may be readily feasible to change the bidi level resolution process from end
of page sequence to end of block. I'll give that a try to see what it breaks,
and if it doesn't break anything that can't be readily fixed, i'll move the
point of resolution invocation to end block processing.
G.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
