[Fwd: Percentages + absolute lengths]

["Peter B. West" <pb...@powerup.com.au>]

FYI

Peter

-------- Original Message --------
Subject: Percentages + absolute lengths
Date: Fri, 07 Feb 2003 02:21:32 +1000
From: Peter B. West <pb...@powerup.com.au>
To: xsl-editors <xs...@w3.org>

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.

The difficulty with respect to such expressions that I have
experienced in implementing FO tree building is that they force
property resolution into dependency on Area tree construction.
Even in the simplest cases, the evaluation of such expressions
assumes the availability of page-based information, as opposed to
the FO tree's flow and static-content view.  I those cases where
the dimensions of areas may be dependent on look-ahead layout
and retries, e.g. during attempts to resolve column widths for
"auto" column layout, the dependency becomes even more tortuous.

The end result is that such expressions must be carried around in
the constructed FO tree, and only resolved as the applicable FO's
areas are generated and returned, or re-generated and returned.
This greatly complicates the expression parsing which must be
done early for the FO tree building to be able to proceed.

While a simple percentage, e.g., "25%", suffers from the same
uncertainties, it can at least be reduced to a single datum,
whose resolution makes no further demands of the expression
parser, which in turn simplifies the parser.

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

The context of this conversion is not property-specific as much
as area-tree specific.

Peter
-- 
Peter B. West  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [Fwd: Percentages + absolute lengths]

["Peter B. West" <pb...@powerup.com.au>]

Fopdevs,

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 <pb...@powerup.com.au>
> To: xsl-editors <xs...@w3.org>
> 
> 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.
> 
...
> 
> 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."

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.

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  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"