The "reference-orientation" property is currently treated as an inheritable property (see FOPropertMapping.createLayoutProperties()), but this is not defined as such in the XSL-FO 1.1 Recommendation (see: 7.21.3, http://www.w3.org/TR/xsl/#reference-orientation) Simply changing the boolean in FOPropertyMapping reveals that we have somehow always worked around this issue. The generation of the region-reference-areas seems to depend on its 'reference-orientation % 90' being equal to that of the simple-page-master. See for example: RegionBody.getViewportRectangle() and Page.setRegionReferencePosition().
Just to keep track of the progress: CTM.getCTMAndRelDims() seems to expect a *relative* reference-orientation (with respect to the ancestor reference-area), so this would mean that we need to pass in the difference between the simple-page-master's reference-orientation and that of the region. Simplest case: <simple-page-master reference-orientation="90" ...> <region-body ...> <!--no explicit value--> CTM.getCTMAndRelDims() expects -90. In current FOP Trunk it gets 90 (inherited value). After fixing FOPropertyMapping, it gets 0.
(In reply to comment #1) > CTM.getCTMAndRelDims() seems to expect a *relative* reference-orientation (with > respect to the ancestor reference-area), Note: the emphasis is due to the fact that the method signature and javadoc indicate that it's an 'absolute' value. When checking the method body, we get the idea of what this 'absolute' refers to.
Created attachment 23362 [details] Proposed fix Patch fixing the issue: very self-contained, since it's only the region-reference-areas' placement that seemed to depend on it. An additional parameter to a private method seemed reasonable enough to meet the requirements of CTM.getCTMAndRelDims().
Andreas - I have a question about your proposed change. Its really only for my understanding: Suppose you have something like: <fo:simple-page-master name="a4"> <fo:region-body reference-orientation="90"/> </fo:simple-page-master> .. <fo:flow flow-name="xsl-region-body> <fo:block>Text1 <fo:block-container> <fo:block>Text2</fo:block> </fo:block-container> </fo:block> </fo:flow> The current behaviour of this is that both Text1 and Text2 will be rotated. After your change can we expect Text1 and Text2 to have a different orientation?
(In reply to comment #4) > Andreas - I have a question about your proposed change. Its really only for my > understanding: Suppose you have something like: > <snip /> > The current behaviour of this is that both Text1 and Text2 will be rotated. > After your change can we expect Text1 and Text2 to have a different > orientation? I think not, and IIC, this should not be the case. Nevertheless, I recently bumped into precisely that effect when nesting block-containers: the inner block-container would inherit the value of the outer block-container, and thus be rotated another 90 degrees relative to the outer b-c reference-area. In the case you present, the region-body is rotated by 90 degrees. So, the flow-reference-area will be rotated by 90 degrees with respect to the page-reference-area. The block-container, having reference-orientation 0 relative to the flow-reference-area, will also be rotated by 90 degrees relative to the page. Result: with normal A4 dimensions (210x297), we will get a portrait page, with both Text1 and Text2 appearing below each other in the page's lower-left corner, rotated by the same amount wrt the page.
(In reply to comment #5) > (In reply to comment #4) > > Andreas - I have a question about your proposed change. Its really only for my > > understanding: Suppose you have something like: > > > <snip /> > > The current behaviour of this is that both Text1 and Text2 will be rotated. > > After your change can we expect Text1 and Text2 to have a different > > orientation? Just noticed: the answer could be Yes or No, depending on what you mean by 'different'. Different with respect to the page? Yes, definitely. Different with respect to each other? No. Just thought I'd clarify...
Forget the patch for the moment. Still too cheap. Just ran some more tests, and after the change: - the content is rotated OK, but... - the clipping rectangle is off (rotated yet another 90 degrees) All the tests I could have known it was not going to be that easy. ;-)
Created attachment 23367 [details] PDF result before and after the patch Sorry, previous remark was too fast again. Redoing the test after reverting the changes shows no difference. In attach, the PDF result for simple-page-master_reference-orientation.xml The layout checks pass, but the issue did appear to exist before... The clipping rectangle is rotated once too many, and the offset due to the page-margins is taken into account twice. Seems to me the region-reference CTM should be an identity CTM, no? (identical to the
The method fop.fo.pagination.Region.getViewportRectangle() returns a rectangle that takes into account the reference-orientation and writing-mode specified on the passed simple-page-master. Note: Not sure why the page-master is needed as an argument, since every Region has access to its parent (which can only be a simple-page-master). Some refactoring of the related classes seems to be in order (see the various implementations in org.apache.fop.fo.pagination). The code blocks for initializing the pageWidthContext and pageHeightContext seem to belong in protected final methods in SimplePageMaster, rather than being repeated in every Region. Anyway, the returned rectangle has a width that is correctly constrained by the page-height if the page-master is rotated. So far, no real problem. The method getViewportRectangle() is used in fop.area.Page. The returned rectangle is transformed by the pageCTM, and stored in RegionViewport as the viewArea. What seems slightly suspicious to me is that the position and dimensions of the region-reference-area are based on that viewArea, without taking into account that it may already be the result of a transform. (i.e. the viewArea's width in absolute terms, will be taken as IPD for the region Currently, for a rotated simple-page-master, the region-reference-area's IPD will be conveniently set to the height of the viewArea, but this seems kind of a fluke... :-/ Since the region inherits the reference-orientation, the CTM that is attached to the RegionReference will also reflect the 'absolute' rotation of the page. If we treat it as a non-inheritable, the value on the region becomes 0, which should mean 'the same orientation as the page-reference-area', but the effect we get is that only the region-viewports appear rotated... The content appears rotated back to the original page-viewport orientation. If we correct this --as happens in the patch-- by passing the region-reference's 'absolute' rotation with regard to the page-viewport to getCTMAndRelDims(), then we get get a correct CTM and dimensions for the region-reference, but for the clipping rectangle the two CTMs (page and region) are combined to transform the viewArea. That one's already transformed, hence why we get the result in the attached PDF.
(In reply to comment #9) Just noticed an unfinished sentence: > taking into account that it may already be the result of a transform. (i.e. the > viewArea's width in absolute terms, will be taken as IPD for the region ... if the region's reference-orientation is 0, which is wrong.
resetting P2 open bugs to P3 pending further review