On 09/03/11 17:34, Andreas Delmelle wrote:
> On 09 Mar 2011, at 00:04, Vincent Hennebert wrote:
<snip/>
>>> The before-edge of the region-viewport-area (V)
>>
>> This is ambiguous. Of which rectangle of the region-viewport-area? The
>> edge is not the same whether we are talking about the
>> border/padding-rectangle or the content-rectangle.
>
> Border/padding are not supposed to play with regions, so that would only
> leave the content-rectangle, no?
The border- and padding-rectangles still exist, they simply coincide
with the content-rectangle. But the naming of edges differs.
> You could ask the same question about the page, and bump into the explicit
> prohibition to use border/padding properties. For a region, background is
> still applicable, so the Common Border Padding and Background properties
> could not be excluded as a whole, but border/padding are still supposed to be
> 0 (spec says 'must'; FOP supports it, nonetheless)
>
> I see what you mean, though: the general definition of the trait derivation
> causes potential conflicts with the definitions a few lines up, for the area
> generation, but only in case the region's reference-orientation deviates from
> the page.
> That is not the normal scenario, and perhaps not supposed to be covered by
> those general definitions (or at least overlooked by the editors).
And that’s where I think correction needs to be brought to the spec, as
this creates the ambiguities we have been discussing about.
>>> You got it completely correct for the reference-orienation on
>>> fo:page-sequence: the page-reference-area is rotated with respect to the
>>> page-viewport-area.
>>> I'm still wondering why the regions would be so much more difficult?
>>
>> The descriptions of fo:simple-page-master and
>> fo:region-before/after/start/end simply are different.
>>
>> Which makes me realize that there is no mention of the
>> page-viewport/reference-area pair in the description of the
>> from-page-master-region() function. Sigh. That one will have to be
>> handled another time I’m afraid.
>
> Good point, and yes, it seems like I was confusing the descriptions between
> simple-page-master and region-*. Region behaves like a block-container...
>
> One could come to the conclusion that a specified reference-orientation on
> fo:simple-page-master has no direct effect, /unless/
> from-page-master-region() is used. It's not a region per se, but satisfies
> the -master- part at least. :-/
Yes, that’s a possible solution. That would be in accordance with the
3rd bullet point I mentioned in my first message:
“The reference-orientation of the page-reference-area and
writing-mode of the page-viewport-area are determined by the
formatting object that generates the area (see 6.4.5
fo:page-sequence).”
The alternative is to leave the description of from-page-master-region()
unchanged, remove that 3rd bullet point, and make the first 2 prevail
(basically, “The ‘writing-mode’ of the page is used to determine the
placement of the five regions on the master.”).
> So, the 'proper' way in 1.1 is to use reference-orientation on the
> fo:page-sequence.
> This got me thinking: if both the page-reference-area's and the
> region-viewport-area's rotations are determined by the fo:page-sequence, then
> what happens if I say reference-orientation="90" there? The
> page-reference-area would be rotated 90 degrees, and the region's --another
> 90? Starting from the already rotated page-reference-area?
Indeed. At any rate, that’s also how I understand it.
> That would seem unexpected, to say the least. I must be missing something
> else...
Maybe. Me too, then ;-)
>>> It's the same principle:
>>> * viewport-area: implicit reference-orientation="0"
>>> * reference-area: reference-orientation as specified
>>
>> That is simply not true. I think the excerpts I took from the
>> specification are clear enough on this regard.
>
> I see what you are referring to, and I am now beginning to think that this is
> just the type of ambiguity that was meant to be reduced in the revised
> definitions. If only there were not the backward compatibility scenario...
>
> Chewing on that for a while, it suddenly becomes clear to what extent 1.1
> *did* simplify matters in this regard.
>
> Strictly speaking, provided that the behavior I described above is wrong, and
> it was really the intention of having the regions just 'follow' the page (no
> additional rotation), there are only two ways to have the
> reference-orientation for a region's content deviate from that of the page:
> 1° use from-page-master-region() in combination with reference-orientation on
> the region
> 2° use a fo:block-container as the sole child of the fo:static-content, and
> specify the reference-orientation there
>
> The first option clearly was added only to allow for easy transitioning from
> 1.0. The required updates to stylesheets are trivial, where adding a
> fo:block-container to every fo:static-content is rather invasive. Breaking
> completely with the 1.0 approach, and requiring people to make the invasive
> changes, would probably have been the cleaner path. If resolving ambiguities
> was what it was about, that is... I guess time and money got their vote too,
> and from-page-master-region() was born. ;-)
>
> In 1.1, the region's reference-orientation, by definition and by default
> would follow the page's. It is only by resorting to either of the above
> tricks that you can create situations that deviate from that normal
> situation.
>
> The second option might reduce the potential confusion somewhat. The rotation
> is more explicitly localized to the region's content, but visually, the
> end-result is the same.
>
> If it is the intention to propagate/maintain the from-page-master-region()
> "hack" (on our end, but also @W3C), there is need for clarification still, as
> to:
> - either what that 'before-edge of the content-rectangle this
> region-viewport-area' means (area generation)
> - or the relationship between the region-viewport and region-reference, in
> terms of reference-orientation (trait derivation)
I’ll send a bug report to the W3C about that.
> Is the region's viewport/reference pair supposed to behave like the page's or
> like a block-container's (as the definition of trait derivation implies)?
> If it's the latter, then the first part about the 'before-edge' should be
> extended with 'assuming no change in reference-orientation with respect to
> the page-reference-area'.
>
> Otherwise, it seems impossible to reconcile the two in all scenarios.
>
> At any rate, I would see it as sufficient, for the moment, to assure that FOP
> supports the basic rule.
> For the other scenario, propagate the block-container workaround, and leave
> from-page-master-region() aside for the moment. --The KISS principle! :-)
>
>
> Regards,
>
> Andreas
> ---
Thanks,
Vincent
