On 02 Mar 2011, at 21:30, Vincent Hennebert wrote: To answer the final question first: > Any thoughts?
Yep! Well, not many, but /some/... BTW: there is also Bugzilla 46826, which is related to reference-orientation. It is currently treated as an inherited property, which is non-compliant and leads to all sorts of fun when nesting several levels of block-containers. As soon as there's one with a different reference-orientation, that is inherited by all descendants. Starting with 90, the second level is rotated 180 vs. the original flow, the next 270 etc. Coincidentally, this same 'bug' causes regions to be rotated OK if they just follow the simple-page-master. > aka “The Recommendation Strikes Back” > > I came across a very interesting section of the XSL-FO 1.1 > Recommendation. This is the description of the from-page-master-region > function in section 5.10.4, “Property Value Functions”. IIRC, the related passages were quite different in XSL-FO 1.0, and likely FOP's implementation still leans toward those definitions. Now that I look closer at it --never checked this at the time-- reference-orientation indeed *was* inherited in 1.0. That explains bug #46826. I also vaguely remember reading a warning somewhere on AntennaHouse's website, followed by a recommendation to use the 'from-page-master-region()' function to transfer the reference-orientation to the flow/static-content, in order to force the pre-1.1 behavior. Note that this function did not exist in 1.0 and was added precisely to make it possible to get the same behavior with minimal headache. The non-implemented status is reflected on FOP's compliance page. The implementation of the function itself seems like a simple thing to add. Even someone who doesn't know FOP's codebase should be able to figure it out in no more than one day... (not taking into account preparatory setup + potentially corresponding delays; one debug session using a simple FO document with a supported function call could be enough) > <snip /> > So, if the fo:simple-page-master has a “reference-orientation” of 0 and > the fo:page-sequence a “reference-orientation” of 90, who wins? Let’s > assume that the first 2 bullet points above are only vague descriptions > and that the 3rd point is normative. Indeed, and that is why, I believe, the definitions were changed. Because it lead to incomprehensible, or at least unexpected results that were very difficult to sell to end-users. IIRC, in 1.0 the reference-orientation on the page-sequence, flow or static-content would only have had effect on block-containers and tables (due to inheritance + a new viewport/reference pair), while the normal flow's and the side-regions' base orientations were determined by the simple-page-master. That seems to come close to what FOP currently implements. <snip /> > Because the from-page-master-region function is used, the > “reference-orientation” property specified on the fo:simple-page-master > and the regions is used to determine their orientations. > > So the content-rectangle of the page-reference-area is like this: > <snip /> > While the content-rectangle of the region-viewport-area for the > region-before is supposed to be like this: > <snip /> > which is completely inconsistent with the description of > fo:region-before: > “The before-edge of the content-rectangle of this > region-viewport-area is positioned coincident with the before-edge > of the content-rectangle of the page-reference-area generated using > the parent fo:simple-page-master. The block-progression-dimension of > the region-viewport-area is determined by the extent trait on the > fo:region-before formatting object.” Unless ... the viewport is where the actual rotation takes place. IIC, the region-viewport's before-edge is still parallel to the page-reference-area's before edge. The before-edge of the region-reference-area, however, is the one that is rotated another 90 degrees... If, by content-rectangle, one refers to the viewport, then there might be no inconsistency (?) <snip /> > Unless, of course, I have completely missed the point, which might well > be the case. Only forgot to check the history/legacy --as did I when I filed bug #46826 Regards, Andreas ---