Hi Stephan,
Stephan Thesing wrote:
Hello,
snip/
My idea is now along the following lines:
- Remember for each element during parsing the change bars it is
influenced by.
- After layout, go over all areas produced by those influenced elements
and add the areas for the change bars
On 03 Sep 2009, at 22:07, Stephan Thesing wrote:
Hi Stephan,
snip /
Seems reasonable, although... validateChildNode() is more meant to
take care of very specific cases, mentioned in the definition of the
content model. Now I'm thinking: a change-bar-* is a neutral item
that
is basically
Hi Stephan,
Stephan Thesing wrote:
Hello,
just a short status / question update.
snip/
What remains is layout and producing the change bar areas.
If I read the spec right, the intended semantics of the change-bar-elements
is the following:
- for all elements generating areas that
Hello,
Yep, that's what I was referring to, and AFAICT, it is not mandated
that the change-bar-begin and the corresponding change-bar-end appear
in the same flow/page-sequence.
yes, it can occur across page-sequences, etc.
Seems reasonable, although... validateChildNode() is more
Hello,
The area tree described in the Recommendation is non-normative,
therefore we are free to deviate from it as long as the final visual
result is the same.
And I’m actually not keen on the idea of generating a change-bar area
for /each/ area under the influence of a change bar. This
Hello,
just a short status / question update.
I have added the fo:change-bar-begin/end elements with their properties.
Validation is also implemented, but:
- In contrast to the other fo: elements, the change-bar-* elements
are allowed to occur everywhere, as long as they have an
On 02 Sep 2009, at 20:22, Stephan Thesing wrote:
Hi Stephan
just a short status / question update.
I have added the fo:change-bar-begin/end elements with their
properties.
Validation is also implemented, but:
- In contrast to the other fo: elements, the change-bar-* elements
are
