On 09 Mar 2011, at 00:04, Vincent Hennebert wrote: <snip />
> Why?? Where in the spec is that interpretation of the term > ‘reference-area’ given? > > OTOH, in Section 4.2.2: “An area for which [the is-reference-area] trait > is true is called a reference-area.” Arrghh, too liberal interpretation from my end. Totally missed that the region's V/R pair behaves more like that of a block-container than that of a page. Still, read on, as we must judge whether it is really worth investing too much time in this scenario. >> 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? 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). >> 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. :-/ 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? That would seem unexpected, to say the least. I must be missing something else... >> 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) 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 ---
