DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #11 from Glenn Adams gl...@skynav.com 2012-04-07 01:41:58 UTC --- resetting P2 open bugs to P3 pending further review -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 Glenn Adams gl...@skynav.com changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #9 from Andreas L. Delmelle adelme...@apache.org 2009-03-22 02:05:39 PST --- 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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #4 from Chris Bowditch bowditch_ch...@hotmail.com 2009-03-10 07:50:43 PST --- 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:blockText1 fo:block-container fo:blockText2/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? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #5 from Andreas L. Delmelle adelme...@apache.org 2009-03-10 10:43:40 PST --- (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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #7 from Andreas L. Delmelle adelme...@apache.org 2009-03-10 11:48:16 PST --- 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. ;-) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #8 from Andreas L. Delmelle adelme...@apache.org 2009-03-10 12:38:19 PST --- Created an attachment (id=23367) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23367) 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 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #1 from Andreas L. Delmelle adelme...@apache.org 2009-03-09 11:32:21 PST --- 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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #2 from Andreas L. Delmelle adelme...@apache.org 2009-03-09 11:48:49 PST --- (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. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826 --- Comment #3 from Andreas L. Delmelle adelme...@apache.org 2009-03-09 13:16:50 PST --- Created an attachment (id=23362) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=23362) 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(). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
