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. 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
