On 21/10/11 08:29, Glenn Adams wrote: > On Thu, Oct 20, 2011 at 10:31 PM, Peter Hancock > <peter.hanc...@gmail.com>wrote: > >> >> From the surface I would have been very much in favor of supporting a >> merge in the near future, however I have had the chance to review some >> areas of the complex script branch and I have some concerns. >> The treatment of Unicode Bidi spans from the creation of the FO Tree >> through to the construction of the Area Tree and I would have liked to >> have seen the complex scripts solution integrate the Unicode Bidi >> Algorithm more directly into the core process: For example, the >> implementation performs a post process on the FO Tree to resolve the >> Bidi properties of FONodes relating to text. It would be preferable to >> see the construction of the FO Tree embracing this Bidi aspect: >> FONodes should be responsible for determining their own bidi state >> from the fo node semantics in context to the position in the tree. >> Such an implementation would immediately force the maintainer to >> consider how a change would effect the Bidi process. >> > > Please review XSL-FO 1.1 Section 5.8, and, in particular: > > "the algorithm is applied to a sequence of characters coming from the > content of one or more formatting objects. The sequence of characters is > created by processing a fragment of the formatting object tree. A *fragment* > is > any contiguous sequence of children of some formatting object in the tree. > The sequence is created by doing a pre-order traversal of the fragment down > to the fo:character level." > > "the final, text reordering step is not done during refinement. Instead, the > XSL equivalent of re-ordering is done during area tree generation" > > The current implementation adheres to the XSL-FO specification in this > regard, while your suggestion that this behavior be isolated to individual > FONodes is contrary to the specification and does not permit correct > implementation of the functionality required.
Section 5 of the XSL-FO 1.1 Recommendation starts with the following note: “Although the refinement process is described in a series of steps, this is solely for the convenience of exposition and does not imply they must be implemented as separate steps in any conforming implementation. A conforming implementation must only achieve the same effect.” So we are free to implement the algorithm any way we see adequate. But even so, a fragment is “any contiguous sequence of children of some formatting object in the tree“. That formatting object doesn’t have to be a whole page-sequence and can as well be a single block or inline or anything else. Implementing Bidi in individual FONode sub-classes allows to keep the treatment encapsulated in each FO element, and adapt it to the specific semantics of that element. If this is done in a single BidiUtil class, all the behaviours that are specific to each element are mixed together. Implementation details that should be kept within individual classes are being exposed to the rest of them. Elements must be handled in lenghty sequences of if/else statement using ‘instanceof’ and casts to the concrete class. If a new FO element is being implemented this will be very likely that it will be forgotten to add the appropriate ‘if’ statement for that element in the BidiUtil class. If it’s not forgotten, it will be difficult to find out where to put that statement. Doing treatment specific to an object outside its implementation screams for trouble and regressions as soon as a change is made in one or the other place. Unless people are aware that they must keep an eye on that BidiUtil class, which is unlikely for newcomer who don’t know the code well. This BidiUtil class has clearly been written in a procedural style, and there are reasons why that style was abandoned years ago in favour of an object-oriented paradigm, that allows to write more flexible, maintainable programs, and easier to understand by people who are not the original authors. I’d like to know what’s your view on this? > I realize this is a complex subject area that requires considerable domain > knowledge, but you can take my word as a domain expert (having implemented > this functionality multiple times in commercial products) that the approach > I have taken is (1) the most consistent with the XSL-FO specification, (2) > the behavior required to achieve the desired functionality, and (3) the > minimum changes and points of dependency to existing code. > > In contrast, a more distributed approach such as you suggest would (1) > diverge from XSL-FO specified behavior, (2) increase and distribute the > number of points of interaction with existing code so as to make behavior > harder to understand, test, and debug, and, most telling, (3) not provide > any functional or performance advantage. > > Regards, > Glenn Thanks, Vincent
