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

Reply via email to