from-page-master-region()

The editors,

Section 5.10.4 Property Value Functions, of Extensible Stylesheet
Language (XSL) Version 1.1, W3C Working Draft 16 December 2004, contains:

<quote>
object from-page-master-region(NCName?)

The from-page-master-region function returns the computed value of the
property whose name matches the argument specified, or if omitted for
the property for which the expression is being evaluated.

In XSL 1.1 this function may only be used as the value of the
"writing-mode" and "reference-orientation" properties. In addition the
argument of the function must be omitted. If an argument is present, it
is an error.

The computed value of the designated property is taken from that
property on the layout formatting object being used to generate the
region viewport/reference area pair.

If this function is used in an expression on a formatting object, F,
that is a descendant of an fo:page-sequence, then the computed value is
taken from the region specification that was used to generate the
nearest ancestor region reference area which has as its descendants the
areas returned by F.

If the argument specifies a property of a compound datatype and if the
expression only consists of the inherited-property-value function with
an argument matching the property being computed, it is interpreted as
an expansion with each component of the compound property having a value
of inherited-property-value with an argument matching the component. It
is an error if arguments matching a property of a compound datatype are
used in any other way.
</quote>

This, incidentally to my comments, should probably read:
<text>
object from-page-master-region()

The from-page-master-region function returns the computed value of the
property for which the expression is being evaluated.

In XSL 1.1 this function may only be used as the value of the
"writing-mode" and "reference-orientation" properties. Note that it is
an error if an argument is provided to this function.

The computed value of the target property is the computed value of that
property on the layout formatting object being used to generate the
region viewport/reference area pair.

If this function is used in an expression on a formatting object, F,
that is a descendant of an fo:page-sequence, then the computed value is
taken from the region specification that was used to generate the
nearest ancestor region reference area which has as its descendants the
areas returned by F.
</text>

The existing version of this text, in particular, draws attention to two
aspects of this definition. Firstly, it has a very restricted
application. Secondly, while it is based on other property value
functions, it's form is distinctly different from its companion
functions.  In other words, it feels like a kludge.

The restrictions of "lexical" inheritance in XSL-FO have been discussed
over a period of years, motivated by the need for some form of
inheritance from the page-masters.  Although I have not thought this
through, I offer the following suggestions in the hope that they may
stimulate discussion.

The two properties involved take effect on reference-areas. In Appendix
C.3 Property Table: Part II, under "Trait mapping", both have "See
prose", i.e. they participate in the definition of other traits.  Traits
apply only to areas.  Many are derived directly from FO properties;
others, like "writing-mode" and "reference-orientation" take effect only
in the development of traits on areas.  Might it be possible to provide
for direct inheritance of traits?

There exists already a model for "dynamic" inheritance, i.e.,
fo:marker/fo:retrieve-marker, and the newly proposed
fo:retrieve-table-marker.  It has been the cause of a great deal of
anguish, for me and other FOP developers at least, but most XSL
developers have found a solution to the problem.  What if a subset of
traits were defined to inherit directly from properties on their area's
controlling simple-page-master?  This set would not be extensive, so the
inheritance tree would not be particularly cpu or memory intensive.

This would entail either a) a change to the manner of inheriting
existing properties, or b) the definition of new properties whose
inheritance and usage characteristics are so defined.  Method b) brings
with it the necessity to arbitrate between. e.g., the existing
"writing-mode" and the new, say, "area-writing-mode".  I lean to using
a) in association with a switch that determines whether the old or new
mode is in effect.  The switch would default to 1.0 behaviour,
preserving the layout of existing fo: stylesheets.  It seems to me that
such a switch could be specified in fo:declarations.

Peter B. West
Project Defoe <http://defoe.sourceforge.net/>

Received on Wednesday, 12 January 2005 05:55:00 UTC