You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2003/05/22 02:17:33 UTC
Thoughts on design - FO property expressions
Fopdevs,
(I am repeating myself in some of what follows. Please bear with me.)
I have been thinking some more about the implications of integrating my
work on the FO tree front end into the redesign. As I mentioned before,
I have come to the conclusion that FO property expressions will require
that the composition of the enclosing areas be complete before they can
be finalized. While this requirement is only a *necessity* for those
expressions which contain a percentage length relative to an enclosing
area dimension, this natural form of length expression, particularly
when arithmetically combined with a constant length (e.g. "25% + 3pt")
is a thorn in the side of any model that tries to isolate FO tree
construction from area tree construction.
My approach in the existing alt.design code was to define IndirectValue
types, anad parse the expressions down to such indirect values when a
percentage was involved. I was *very* keen to avoid carrying the whole
expression around and re-evaluating it as many times as required. The
price I paid for this was the inability to handle "25% + 3pt"
expressions, which I could not resolve to a single PropertyValue type,
i.e., to an IndirectValue.
Property expressions must be evaluated early, in order, e.g., for the
layout-master-set to be developed, but the thought of going through the
process more than once irks me greatly. I am thinking of extending the
concept of the IndirectProperty value to include arithmetic length
expressions of multiple Numerics, superceding the existing
IndirectValues. Some form of indirection would still be required,
because inheritance is in terms of the computed value of property
expressions, so it makes no sense to inherit the percentage. I.e, if
some descendant of an FO with some property value of "80%" inherits that
value, it inherits the resolved value, not a percentage defined against
a possibly different reference area. (This is off the top of my head.
I have to returned to the spec to check this.)
The point of defining an ArithmeticLengthExpressions PropertyValue type
would be to take advantage of the first pass of the parser over the raw
expression. Anyone who has looked at the extended parser code of
alt.design, or even of the main line code, will realise that such a goal
is worthwhile.
I am open to advice on the form that such a value type would take. I
suspect that an (R)PN expression would be the best bet. Any suggestions?
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> I have come to the conclusion that FO property expressions will require
> that the composition of the enclosing areas be complete before they can
> be finalized.
It is worse:
<fo:root>
<fo:layout-master-set>
<fo:simple-page-master master-name="m1" height="10cm" width="10cm">
<fo:region-body/>
</fo:simple-page-master>
<fo:simple-page-master master-name="m2" height="10cm" width="5cm">
<fo:region-body/>
</fo:simple-page-master>
<fo:page-sequence-master name="m">
<fo:single-page-master-reference master-reference="m1"/>
<fo:single-page-master-reference master-reference="m2"/>
</fo:page-sequence-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="m">
<fo:flow flow-name="xsl-region-body">
<fo:block text-indent="1cm+10%">
<fo:block>Lorem</fo:block>
<fo:block break-before="page">ipsum</fo:block>
</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
I interpret the spec as follows:
- "Lorem" is indented by 2cm
- "ipsum" is indented by 1.5cm
Unfortunately, the spec is not always clear whether the "computed
value" (2cm) or the "specified value" (1cm+10%) of a property is
inherited. Usually it should be the latter, in order for font size
dependent stuff to make sense.
(feel free to nitpick: the spec states for text-indent
Value: <length> | <percentage> | inherit
i.e. not mixing both, and
Percentages: refer to width of containing block
whatever...)
Note that plain percentages are still bad.
> I was *very* keen to avoid carrying the whole
> expression around and re-evaluating it as many times as required.
...
> I am open to advice on the form that such a value type would take. I
> suspect that an (R)PN expression would be the best bet. Any suggestions?
Look into a good compiler, like gcc, how they do it. There's
stuff called Constant Folding at work.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "Peter B. West" <pb...@powerup.com.au>.
I am only aware of one case in which the specified value is inherited,
and that is a special case of an em specifier, where a de facto em value
is specified as a number. I can't remember off-hand where it is.
Peter
J.Pietschmann wrote:
> Glen Mazza wrote:
>
>> Yes--section 5.1.4 of the specification says it is the
>> computed value (which is not necessarily the specified
>> value) that is inherited.
>
>
> Ouch!
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Glen Mazza wrote:
> Yes--section 5.1.4 of the specification says it is the
> computed value (which is not necessarily the specified
> value) that is inherited.
Ouch!
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: AW: Thoughts on design - FO property expressions
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
> Peter B. West wrote:
>
> You seem to be familiar with some of the
> swing.javax.text classes.
Yes, as a user of these classes: no need to know internals.
> Can you sketch the approach out in a bit more
> detail? Have you looked at percentages?
>
See a description javax.swing.text: Interface Document. There is HTML
support. Perhaps an evaluation of an XSL adaption makes sense.
Asap I will try to embed HTML into FOP documents and test your percentages.
If it works, find out how. If not, find out what HTML specifies on
percentages.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: AW: Thoughts on design - FO property expressions
Posted by "Peter B. West" <pb...@powerup.com.au>.
Hansuli,
No, I haven't. You seem to be familiar with some of the
swing.javax.text classes. Can you sketch the approach out in a bit more
detail? Have you looked at percentages?
Peter
J.U. Anderegg wrote:
> Peter,
>
> did you ever study swing.javax.text? How does this HTML editor handle
> percentages? There are also gadgets like this:
>
> javax.swing.text Class BoxView java.lang.Object
>
> ... A view that arranges its children into a box shape by tiling it's
> children along an axis. The box is somewhat like that found in TeX where
> there is alignment of the children, flexibility of the children is
> considered, etc. This is considered an useful building block that might be
> useful to represent things like a collection of lines, paragraphs, lists,
> columns, pages, etc.
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
AW: Thoughts on design - FO property expressions
Posted by "J.U. Anderegg" <ha...@bluewin.ch>.
Peter,
did you ever study swing.javax.text? How does this HTML editor handle
percentages? There are also gadgets like this:
javax.swing.text Class BoxView java.lang.Object
... A view that arranges its children into a box shape by tiling it's
children along an axis. The box is somewhat like that found in TeX where
there is alignment of the children, flexibility of the children is
considered, etc. This is considered an useful building block that might be
useful to represent things like a collection of lines, paragraphs, lists,
columns, pages, etc.
Hansuli Anderegg
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "Peter B. West" <pb...@powerup.com.au>.
Peter B. West wrote:
>
>
> All of this means that more strings and PropertyValue objects are being
> carried around while the Area tree is being resolved, and all to
> circumvent multiple passes through a parser, and complications about
> exactly when certain expressions are to be resolved. Whether this
> approach is better or worse than keeping the expression and arranging
> for multiple passes is, I suppose, moot. My own feeling is that this
> approach is somehow cleaner from a design point of view.
Considering that the relative frequency of expressions unresolvable at
the FO tree level is low, the above really isn't much of an issue. The
benefits will far outweigh the disadvantages.
The only other issue that I can see is the late detection of errors,
without any environment for meaningful error messages.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Peter B. West wrote:
>
>> Basically, because there are three grammars at work.
>
> ...
>
>> the bizarre syntax requirements of the Rec
>
> Hehe!
>
> Actually you know beforehand what kind of grammar you get,
> there is *no* need to have a unified parser. I was always
> amazed by the hoops the maintenance code goes through.
Alt.design has added hoops.
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> Basically, because there are three grammars at work.
...
> the bizarre syntax requirements of the Rec
Hehe!
Actually you know beforehand what kind of grammar you get,
there is *no* need to have a unified parser. I was always
amazed by the hoops the maintenance code goes through.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Peter B. West wrote:
>
>> That could be done fairly simply without creating too many extra
>> objects by adding an operator field as a string to the
>> length/percentage PropertyValues, and building a list from the
>> expression.
>
> ...
>
> What's wrong with parse trees produced by a recursive descendence
> parser like ANTLR produces, or perhaps a LALR(1) parser? (The
> XSLFO property expression grammar should be LR(1), I think).
> Of course, there are actually three grammars at work:
> - whitespace separated lists for some of the shorthand properties,
> - the comma separated, optional whitespace list for font-family
> - all the rest, with fallback to the original lexical string
> if the type of the expression turns out to be wrong or some other
> problem occurs (like hyphenation-char="-" [syntax error] or
> page-number-format="01")
> Constant folding can be applied to the tree, either during
> construction or afterwards. This also solves the problem of
> the get-nearest-specified() stuff nicely, just replace the
> function call with the parse tree from the referenced property
> and redirect the base of the percentage values. Of course
> markers have to keep the call.
Basically, because there are three grammars at work. I've been through
the agony of extending the parser to cope with the bizarre syntax
requirements of the Rec, and I don't particularly want to start again.
However, if you see a better way, please explore. I tried to get
immediately useful output from the parsing, but there is still an
refineParsing stage to decode complex attribute values, like "font".
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> That could be done fairly simply without creating too many extra objects
> by adding an operator field as a string to the length/percentage
> PropertyValues, and building a list from the expression.
...
What's wrong with parse trees produced by a recursive descendence
parser like ANTLR produces, or perhaps a LALR(1) parser? (The
XSLFO property expression grammar should be LR(1), I think).
Of course, there are actually three grammars at work:
- whitespace separated lists for some of the shorthand properties,
- the comma separated, optional whitespace list for font-family
- all the rest, with fallback to the original lexical string
if the type of the expression turns out to be wrong or some other
problem occurs (like hyphenation-char="-" [syntax error] or
page-number-format="01")
Constant folding can be applied to the tree, either during
construction or afterwards. This also solves the problem of
the get-nearest-specified() stuff nicely, just replace the
function call with the parse tree from the referenced property
and redirect the base of the percentage values. Of course
markers have to keep the call.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area Tree vs. subsequent renderer (was Re: FO property expressions)
Posted by Jeremias Maerki <de...@greenmail.ch>.
Peter's right. We've done some loud thinking a few months back (Dec/Jan,
I think) about the possibility to create several output files from the
same area tree. At the moment anyway, the renderer provides the fonts
and the layout engine adjusts to that. So, that means that the area tree
differs depending on the renderer used. That can be improved but only by
making a central font registry. The renderer would then announce which
font sources it supports. It's all in the archives.
On 02.06.2003 14:27:07 Peter B. West wrote:
> > For those output formats requiring an area tree (i.e.,
> > non-TXT, RTF, etc.), the area tree is independent of
> > the renderer, correct?
> >
> > I.e., the area tree created for a document will be
> > the same for all renderers, and the area tree is
> > created without taking into account its subsequent
> > renderer.
>
> In general, no. Most of the atoms composing the area tree are character
> glyphs. How they are composed on the page depends on their metrics.
> The font metrics may vary from renderer to renderer. For this reason,
> the target renderer (or at the very least the font metrics associated
> with the renderer) must be known. Jeremias, Victor and others have been
> concerned with factoring out a fonts subsystem, so they may be able to
> promise that for FOP this issue will be resolved.
>
> I know nothing at all about image rendering, but there may also be
> renderer dependencies in the composition of images.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Area Tree vs. subsequent renderer (was Re: FO property expressions)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Glen Mazza wrote:
> Thanks, Peter, for the explanation on the
> property/inheritance computations--I have one more
> question, perhaps anyone can answer (The Area
> Tree/Renderer explanations on the Design Tab is
> somewhat vague on this point):
>
> For those output formats requiring an area tree (i.e.,
> non-TXT, RTF, etc.), the area tree is independent of
> the renderer, correct?
>
> I.e., the area tree created for a document will be
> the same for all renderers, and the area tree is
> created without taking into account its subsequent
> renderer.
Glen,
In general, no. Most of the atoms composing the area tree are character
glyphs. How they are composed on the page depends on their metrics.
The font metrics may vary from renderer to renderer. For this reason,
the target renderer (or at the very least the font metrics associated
with the renderer) must be known. Jeremias, Victor and others have been
concerned with factoring out a fonts subsystem, so they may be able to
promise that for FOP this issue will be resolved.
I know nothing at all about image rendering, but there may also be
renderer dependencies in the composition of images.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Area Tree vs. subsequent renderer (was Re: FO property expressions)
Posted by Glen Mazza <gl...@yahoo.com>.
Thanks, Peter, for the explanation on the
property/inheritance computations--I have one more
question, perhaps anyone can answer (The Area
Tree/Renderer explanations on the Design Tab is
somewhat vague on this point):
For those output formats requiring an area tree (i.e.,
non-TXT, RTF, etc.), the area tree is independent of
the renderer, correct?
I.e., the area tree created for a document will be
the same for all renderers, and the area tree is
created without taking into account its subsequent
renderer.
Thanks,
Glen
--- "Peter B. West" <pb...@powerup.com.au> wrote:
> Glen,
>
> Sorry about the late reply, but this has only just
> arrived. See
> comments below.
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by "Peter B. West" <pb...@powerup.com.au>.
Glen,
Sorry about the late reply, but this has only just arrived. See
comments below.
Glen Mazza wrote:
> --- "Peter B. West" <pb...@powerup.com.au> wrote:
>
>>Fopdevs,
>>
>>As I mentioned before,
>>I have come to the conclusion that FO property
>>expressions will require
>>that the composition of the enclosing areas be
>>complete before they can
>>be finalized.
>
>
>>While this requirement is only a
>>*necessity* for those
>>expressions which contain a percentage length
>>relative to an enclosing
>>area dimension, this natural form of length
>>expression, particularly
>>when arithmetically combined with a constant length
>>(e.g. "25% + 3pt")
>>is a thorn in the side of any model that tries to
>>isolate FO tree
>>construction from area tree construction.
>>
>
>
> I think the "thorn" is the attempt to resolve all
> specified values into computed values in the FO tree,
> correct?
>
> Just for my learning here, shouldn't the FO tree just
> store specified values (whether absolute or relative),
> leaving the resolution into computed values to the
> area tree? What is lost by having the computed values
> determined solely within area tree construction?
Only percentages are a problem, but they cannot be regarded as an
optional extra. Parsing of the expressions must start before area tree
construction can begin. The layout-master-set must be constructed, and
its property expressions resolved, and the master-reference of the first
page-sequence must be parsed in order to construct the first area.
Inheritance is expressed in terms of the FO tree. In all cases but, I
think, one, inheritance is of the computed value, as you point out.
That means that the computed value ancestry must be available in order
to resolve FO tree values. from-nearest-specified-value() imposes some
other awkward conditions, especially for the "re-parented" fo:marker
subtrees when attached to the static-content FO subtree by an
fo:retrieve-marker.
It would be messy to try to discriminate cases requiring early
resolution from those which do not in the first pass of parsing the XML
input and building the FO tree. That's why it seems to me best to do as
much of the parsing as possible at entry, and resolve arithmetic
expressions involving percentages into some form which does not require
the full parser to be invoked. At this stage I am thinking of building
a de facto RPN stack within the existing parser, and resolving that
expression stack as much as possible before returning the value.
That could be done fairly simply without creating too many extra objects
by adding an operator field as a string to the length/percentage
PropertyValues, and building a list from the expression.
(PropertyValuesLists are already used whenever multi-component
expression values occur. In alt.design, they inherit from
PropertyValue, so they can be passed around as the return values of
expressions.)
If VAL can represent an absolute length value, a constant (absolute
length with length specifier to power 0!!) or a percentage, and
VALn['ops'] represents such a value with the operator field set, an
expression list could be built from an expression like so:
((a * ( b + c)) div (d - e)) + f
(VALa, VALb, VALc['+*'], VALd, VALe['-/'], VALf['+'])
As much resolution as possible could be done in the parser (e.g. (CON,
PCNT['*']) ), can be resolved. Note that (LEN, PCNT['*']) is
problematical, giving rise to a LEN with a unit power other than 0 or 1
unless part of a larger expression.
All of this means that more strings and PropertyValue objects are being
carried around while the Area tree is being resolved, and all to
circumvent multiple passes through a parser, and complications about
exactly when certain expressions are to be resolved. Whether this
approach is better or worse than keeping the expression and arranging
for multiple passes is, I suppose, moot. My own feeling is that this
approach is somehow cleaner from a design point of view.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Thoughts on design - FO property expressions
Posted by Glen Mazza <gl...@yahoo.com>.
--- "Peter B. West" <pb...@powerup.com.au> wrote:
> Fopdevs,
>
> As I mentioned before,
> I have come to the conclusion that FO property
> expressions will require
> that the composition of the enclosing areas be
> complete before they can
> be finalized.
> While this requirement is only a
> *necessity* for those
> expressions which contain a percentage length
> relative to an enclosing
> area dimension, this natural form of length
> expression, particularly
> when arithmetically combined with a constant length
> (e.g. "25% + 3pt")
> is a thorn in the side of any model that tries to
> isolate FO tree
> construction from area tree construction.
>
I think the "thorn" is the attempt to resolve all
specified values into computed values in the FO tree,
correct?
Just for my learning here, shouldn't the FO tree just
store specified values (whether absolute or relative),
leaving the resolution into computed values to the
area tree? What is lost by having the computed values
determined solely within area tree construction?
> I.e, if
> some descendant of an FO with some property value of
> "80%" inherits that
> value, it inherits the resolved value, not a
> percentage defined against
> a possibly different reference area. (This is off
> the top of my head.
> I have to returned to the spec to check this.)
Yes--section 5.1.4 of the specification says it is the
computed value (which is not necessarily the specified
value) that is inherited.
Thanks,
Glen
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org