On 03 Sep 2009, at 22:07, Stephan Thesing wrote:
Hi Stephan,
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 allowed an
Hi Stephan,
Stephan Thesing wrote:
> Hello,
>
>>> 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 chang
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. T
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
Hi Stephan,
Stephan Thesing wrote:
> Hello,
>
> just a short status / question update.
>
>
> 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 t
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 allowed
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
fo:flo
