Sorry about the delay in getting the integration wiki going. One of the reasons was that I wanted to formulate a couple of questions to the editors about aspects of the property handling, because the issues had the potential to cause awkward modifications to the code. The one that was most awkward is precised below.
Peter B. West wrote:
-------- Original Message -------- Subject: Percentages + absolute lengths Date: Fri, 07 Feb 2003 02:21:32 +1000 From: Peter B. West <[EMAIL PROTECTED]> To: xsl-editors <[EMAIL PROTECTED]>Please clarify the editors' expectation for the resolution of an expression like "25% + 3pt" an FO where the relative value is resolved in terms of an enclosing reference area.
...
I am sure that I will get caned on this one by the editors. Being able to write "25% + 3pt" is too fundamental and "natural" an expression to suppress, and the spec specifically mentions the resolution of relative lengths within additive expressions, of which "25% + 3pt" is presumably an example. Unfortunately the spec also makes great play of the fact that the FO tree properties are "conceptually" refined in advance of the construction of the area tree.My current implementation of FO tree building rejects expressions such as "25% + 3pt" on the basis that (part of) "...the expression value cannot be converted to the necessary type for the property value," (5.9.12) within the context of the building of the FO tree. This is in spite of the fact that the spec states, fatuously in my view, that, "Properties are evaluated against a property-specific context. This context provides: ... Conversions from relative numerics by type to absolute numerics within additive expressions."
However, the editors have an out. Section 3. Introduction to Formatting, contains this little Catch-22:
"Some of these operations (particularly evaluating expressions) depend on knowledge of the area tree. Thus refinement is not necessarily a straightforward, sequential procedure, but may involve look-ahead, back-tracking, or control-splicing with other processes in the formatter."
This makes a mockery of the whole preceding "conceptual" description of the process, by making quite clear (to those who have already banged their heads against this particular wall) that the FO tree cannot be developed in isolation from the Area tree.
From memory, Ken Holman recently posted a message on the exslfo list in response to a request for the formalisation of access to the FO tree. He noted that one company (which he would not name) had developed a formatter which did not generate an area tree at all. I know why.
Attached is a scratch diagram from my alt.design notes about the relationship between various components if the design, and where I saw the FO tree build fitting in.
At that stage I was still thinking that the FO tree could be built in isolation, but the structure I sketched can still work. The feedback loop labelled "FO completion messages" from the Area tree builder to the FO tree builder becomes busier. It feeds back information on all of the areas that it is building, so that the FO tree builder can construct the area tree context of the FOs it is building.
The basic process of passing events through a buffer is reasonably efficient, as shown by the alt.design FO builder, and the model does allow for clean isolation of components.
The other possibility is to make a nauseating mess of the property parsing, creating special cases for additive expressions containing percentages, and going through the expression parsing again within the area tree build when the appropriate context is available. Note that the parsing already accommodates percentages as special cases through an IndirectValue class. Integrating FO and Area tree builds in the way I am thinking about will eliminate the need for that class, as all percentages would be resolved immediately.
Once it is constructed, there exists always the possibility of optimisations, including the use of some more directly realised use of co-routines, and the elimination of the area tree as a separate entity. From my current perspective, I don't see either of those as strong possibilities.
I will detail these options as I get the Wiki going, but would appreciate any fedback in the meantime.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
<<inline: processPlumbing.png>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
