You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2009/03/09 19:13:39 UTC

DO NOT REPLY [Bug 46826] New: reference-orientation treated as an inherited property

https://issues.apache.org/bugzilla/show_bug.cgi?id=46826

           Summary: reference-orientation treated as an inherited property
           Product: Fop
           Version: 1.0dev
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: fo tree
        AssignedTo: fop-dev@xmlgraphics.apache.org
        ReportedBy: adelmelle@apache.org


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().

-- 
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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #9 from Andreas L. Delmelle <ad...@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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #3 from Andreas L. Delmelle <ad...@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.

DO NOT REPLY [Bug 46826] reference-orientation treated as an inherited property

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #4 from Chris Bowditch <bo...@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: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?

-- 
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

Posted by bu...@apache.org.
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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #6 from Andreas L. Delmelle <ad...@apache.org>  2009-03-10 10:54:08 PST ---
(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...

-- 
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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #8 from Andreas L. Delmelle <ad...@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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #7 from Andreas L. Delmelle <ad...@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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #1 from Andreas L. Delmelle <ad...@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

Posted by bu...@apache.org.
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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #2 from Andreas L. Delmelle <ad...@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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #5 from Andreas L. Delmelle <ad...@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

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46826





--- Comment #10 from Andreas L. Delmelle <ad...@apache.org>  2009-03-22 02:09:22 PST ---
(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.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.