I don't have time to participate in this thread at the moment, but I want to mention that writing mode should have no impact on any CTM produced by a reference orientation. Writing mode is solely used to
(1) resolve the absolute inline and block progression directions (prior to any rotation of reference area due to reference orientation); (2) resolve writing mode relative properties; (3) resolve default block level bidirectional level; In particular, the code in CTM.getWMctm() incorrectly assumed a relationship between WM and CTM. So keep that in mind in this discussion of reference orientation. G. On Wed, Mar 9, 2011 at 12:10 PM, Vincent Hennebert <[email protected]>wrote: > 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 >
