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 Vincent Hennebert <vh...@gmail.com> on 2011/03/02 21:30:04 UTC
reference-orientation on side regions
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”. This function
can be used to determine the computed value of the “writing-mode” and
“reference-orientation” properties. To keep it simple I’ll leave
“writing-mode” aside and assume that it’s always kept to its default
value of “lr-tb”.
Preliminary note: fo:simple-page-master, fo:region-body,
fo:region-before and the like /do not/ generate areas. They are simply
/used/ to generate areas, the actual generation is done by
fo:page-sequence.
fo:simple-page-master is used to generate a page-viewport-area/
page-reference-area pair. The reference-orientation of the
page-viewport-area is set to 0. Now there is, at best, an ambiguity in
the description of Section 6.4.13, “fo:simple-page-master”:
• first there is a note saying “For example, if the writing-mode of the
fo:simple-page-master is ‘lr-tb’, then these regions correspond to the
body of a document, the header, the footer, the left sidebar, and the
right sidebar.”
• then there is this sentence: “The ‘writing-mode’ of the page is used
to determine the placement of the five regions on the master.”
That seems to indicate that the value of the “writing-mode” property set
on the fo:simple-page-master is used to determine the placement of the
regions.
• but further below there is this: “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).”
In Section 6.4.15, “fo:region-before”, there is this: “This region
specifies a viewport/reference pair that is located on the ‘before’ side
of the page-reference-area.”
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.
If we want to use the values specified on the respective regions
instead, then we can use the from-page-master-region function for the
value of the “reference-orientation” or “writing-mode” properties set on
fo:page-sequence, as clearly described in Section 5.10.4.
Now, let’s take the following XSL-FO document:
<?xml version="1.0" standalone="no"?>
<fo:root xmlns:fo="http://www.w3.org/1999/xsl/format">
<fo:layout-master-set>
<fo:simple-page-master master-name="page"
page-width="21cm" page-height="29.7cm" reference-orientation="90">
<fo:region-body margin-top="15pt" reference-orientation="90"/>
<fo:region-before extent="10pt"/>
</fo:simple-page-master>
</fo:layout-master-set>
<fo:page-sequence master-reference="page"
reference-orientation="from-page-master-region()">
<fo:static-content flow-name="xsl-region-before" font-size="8pt">
<fo:block>xsl-region-before</fo:block>
</fo:static-content>
<fo:flow flow-name="xsl-region-body">
<fo:block>lorem ipsum dolor sit amet, consectetur adipiscing elit.
vestibulum arcu felis, gravida vitae laoreet in, molestie nec
libero. mauris non enim diam. pellentesque nisl diam, aliquet
nec euismod vitae, convallis nec massa. mauris gravida arcu ac
erat euismod molestie. maecenas eget neque in sem aliquam
viverra. vivamus dictum lobortis scelerisque.</fo:block>
</fo:flow>
</fo:page-sequence>
</fo:root>
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:
___________________________
| end |
| |
| |
| |
| |
| |
|before |after
| |
| |
| |
| |
| |
| |
|_________________________|
start
While the content-rectangle of the region-viewport-area for the
region-before is supposed to be like this:
after
____
| |
| |
| |
| |
| |
end| |start
| |
| |
| |
| |
| |
|__|
before
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.”
The inconsistency can be resolved by replacing content-rectangle with
border-rectangle in the excerpt above. Because, as explained in Section
4.2.3, “Geometric Definitions”, the definition of the
before/after/start/end-edges of the content-rectangle of an area uses
the inline/block-progression-direction of that area; Whereas the
border/padding/allocation-rectangles use the directions of the parent
area.
Unless, of course, I have completely missed the point, which might well
be the case.
As a side note, FOP does not follow the Recommendation regarding the
implementation of the “reference-orientation” property on
fo:page-sequence. It behaves as if that property was set to
“from-page-master-region()”, whereas it doesn’t even implement that
function.
Why am I raising this topic? Take an XSL-FO document, add a bit of
overflow=“hidden” here and there, a pinch of reference-orientation,
introduce IPD, BPD, clipping rectangles and transformation matrices,
shake well... and you obtain food for thought regarding Bugzilla #49910.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49910
Any thoughts?
Vincent
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 03 Mar 2011, at 13:08, Vincent Hennebert wrote:
>> <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
>
> Frankly, I’m not willing to look at the XSL-FO 1.0 Recommendation.
> I don’t have the energy to understand the logic that’s explained there,
> understanding one version is already hard enough.
Of course. I just meant that it sounded a bit like there was no logic whatsoever behind what is currently implemented. At first, I had my doubts too, until I decided to take a look at 1.0.
The least it does, is offer an explanation as to why things are the way they are.
Regards,
Andreas
---
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 03 Mar 2011, at 21:18, Andreas Delmelle wrote:
> <snip />
> So, specifying reference-orientation="90" on the region rotates its reference-area by 90 degrees from the page-reference-area.
Correction: this is still the 1.0-way of looking at it.
In 1.1, this would have to be something along the lines of:
... specifying reference-orientation="90" on the region, in combination with reference-orientation="from-page-master-region()" on the page-sequence, rotates the region's reference-area ..."
Regards,
Andreas
---
Re: reference-orientation on side regions
Posted by Glenn Adams <gl...@skynav.com>.
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 <vh...@gmail.com>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
>
Re: reference-orientation on side regions
Posted by Vincent Hennebert <vh...@gmail.com>.
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
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 09 Mar 2011, at 00:04, Vincent Hennebert wrote:
<snip />
> Why?? Where in the spec is that interpretation of the term
> ‘reference-area’ given?
>
> OTOH, in Section 4.2.2: “An area for which [the is-reference-area] trait
> is true is called a reference-area.”
Arrghh, too liberal interpretation from my end. Totally missed that the region's V/R pair behaves more like that of a block-container than that of a page.
Still, read on, as we must judge whether it is really worth investing too much time in this scenario.
>> 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?
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).
>> 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. :-/
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? That would seem unexpected, to say the least. I must be missing something else...
>> 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)
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
---
Re: reference-orientation on side regions
Posted by Vincent Hennebert <vh...@gmail.com>.
On 08/03/11 21:14, Andreas Delmelle wrote:
> On 08 Mar 2011, at 21:26, Vincent Hennebert wrote:
>
>>
>> A viewport-area /is/ a reference-area. See section 4.2.2.
>
> I think we're almost there.
>
> From that section:
>
> "A common construct is a viewport/reference pair. This is a viewport-area V and a block-area reference-area R, where R is the sole child of V ... (continued all the way below)"
>
> In 6.4.14 fo:region-body - Areas:
>
> "The fo:region-body formatting object is used to generate one region-viewport-area and one region-reference-area"
>
> Note: *and* implies /two/ areas.
Of course. I’m wondering why you are pointing that out?
> While the region-viewport-area is indeed a reference-area (or more precisely: has a value of true for the is-reference-area trait), that is not the one that is rotated due to reference-orientation of the /region/.
So what does the following sentence from Section 6.4.15 mean then?
“The reference-orientation [...] of the region-viewport-area [is]
determined by the formatting object that generates the area (see
6.4.5 fo:page-sequence).”
> As you pointed out, by definition, the reference-orientation of the region-viewport-area is '0' with respect to the page-reference-area.
That is not what I pointed out. Please re-read my previous message. The
reference-orientation of the region-reference-area is ‘0’ with respect
to the region-viewport-area.
> Saying that the region-reference-area is rotated with respect to the region-viewport-area is thus basically the same thing as saying that it is rotated with respect to the page-reference-area.
> By reference-area, I am referring to the R in the V/R pair described in 4.2.2, not "an area with is-reference-area trait set to true", which would cover the V too.
Why?? Where in the spec is that interpretation of the term
‘reference-area’ given?
OTOH, in Section 4.2.2: “An area for which [the is-reference-area] trait
is true is called a reference-area.”
>> <snip />
>> I am getting a little impatient
>
> OK... Take a deep breath.
I can’t, I have a cold ;-)
>> because the above is in clear contradiction with what is written in the spec.
>
> No, it's not. See above.
>
>> The topic is already complex, I think it’s important to not add to the confusion by making
>> sure we are reading it properly.
>
> I agree. No need to invent contradictions/inconsistencies where there aren't any.
>
>> Would you mind backing your points with references to the spec?
>
> No, I don't mind --and so I did.
>
>> If we take the XSL-FO example I put in my first message:
>
> <snip />
>
> OK, I got that.
>
>> And, as explained in my first message, since the content-rectangle of
>> an area uses the reference-orientation of that area, the description
>> in Section 6.4.15 about how the content-rectangle should be positioned
>> appears to be inconsistent.
>
> No inconsistency here. It explicitly says "content-rectangle of the region-viewport-area".
>
>>
>> The reference-orientation of the region-reference-area is the same as
>> the one from the region-viewport-area:
>
> Unless the region-reference-area is rotated further, as is the case in the example. That is the point exactly.
Again, the reference-orientation of the region-reference-area is 0.
> 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.
> coincides with the before-edge of the page-reference-area, while the before-edge of the region-reference-area (R) coincides with the start-edge of the region-viewport-area (and ultimately also the page-reference-area).
>
> That is special behavior compared to the normal case (no rotation), as described in 4.2.2:
>
> "(continued from above) ... and where the start-edge and end-edge of the content-rectangle of R are parallel to the start-edge and end-edge of the content-rectangle of V."
>
> 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.
> 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.
> Regards,
>
> Andreas
Vincent
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 08 Mar 2011, at 21:26, Vincent Hennebert wrote:
>
> A viewport-area /is/ a reference-area. See section 4.2.2.
I think we're almost there.
From that section:
"A common construct is a viewport/reference pair. This is a viewport-area V and a block-area reference-area R, where R is the sole child of V ... (continued all the way below)"
In 6.4.14 fo:region-body - Areas:
"The fo:region-body formatting object is used to generate one region-viewport-area and one region-reference-area"
Note: *and* implies /two/ areas.
While the region-viewport-area is indeed a reference-area (or more precisely: has a value of true for the is-reference-area trait), that is not the one that is rotated due to reference-orientation of the /region/.
As you pointed out, by definition, the reference-orientation of the region-viewport-area is '0' with respect to the page-reference-area. Saying that the region-reference-area is rotated with respect to the region-viewport-area is thus basically the same thing as saying that it is rotated with respect to the page-reference-area.
By reference-area, I am referring to the R in the V/R pair described in 4.2.2, not "an area with is-reference-area trait set to true", which would cover the V too.
> <snip />
> I am getting a little impatient
OK... Take a deep breath.
> because the above is in clear contradiction with what is written in the spec.
No, it's not. See above.
> The topic is already complex, I think it’s important to not add to the confusion by making
> sure we are reading it properly.
I agree. No need to invent contradictions/inconsistencies where there aren't any.
> Would you mind backing your points with references to the spec?
No, I don't mind --and so I did.
> If we take the XSL-FO example I put in my first message:
<snip />
OK, I got that.
> And, as explained in my first message, since the content-rectangle of
> an area uses the reference-orientation of that area, the description
> in Section 6.4.15 about how the content-rectangle should be positioned
> appears to be inconsistent.
No inconsistency here. It explicitly says "content-rectangle of the region-viewport-area".
>
> The reference-orientation of the region-reference-area is the same as
> the one from the region-viewport-area:
Unless the region-reference-area is rotated further, as is the case in the example. That is the point exactly.
The before-edge of the region-viewport-area (V) coincides with the before-edge of the page-reference-area, while the before-edge of the region-reference-area (R) coincides with the start-edge of the region-viewport-area (and ultimately also the page-reference-area).
That is special behavior compared to the normal case (no rotation), as described in 4.2.2:
"(continued from above) ... and where the start-edge and end-edge of the content-rectangle of R are parallel to the start-edge and end-edge of the content-rectangle of V."
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?
It's the same principle:
* viewport-area: implicit reference-orientation="0"
* reference-area: reference-orientation as specified
Regards,
Andreas
Re: Font Weights
Posted by Glenn Adams <gl...@skynav.com>.
Joshua,
Please take up this question on the FOP-USERS mail list where you started.
Regards,
Glenn
On Tue, Mar 8, 2011 at 4:41 PM, Marquart, Joshua D <
joshua.marquart@firstdata.com> wrote:
> I had a question in the fop-users for Font Weight regarding relative weight
> fonts, but apparently:
>
> 7.9.9
> font-weight
> Basic
> partial
> partial
> partial
> TODO <relative> font weights
>
> I'm thinking we probably need additional font metrics xml files in the
> src\codegen\fonts folder.
>
> :-)
>
> So... who is the expert on font weight here and how can you I help you
> generate the right metrics to get this working?
>
> -Josh
>
Font Weights
Posted by "Marquart, Joshua D" <jo...@firstdata.com>.
I had a question in the fop-users for Font Weight regarding relative weight fonts, but apparently:
7.9.9
font-weight
Basic
partial
partial
partial
TODO <relative> font weights
I'm thinking we probably need additional font metrics xml files in the src\codegen\fonts folder.
:-)
So... who is the expert on font weight here and how can you I help you generate the right metrics to get this working?
-Josh
-----Original Message-----
From: Vincent Hennebert [mailto:vhennebert@gmail.com]
Sent: Tuesday, March 08, 2011 3:27 PM
To: fop-dev@xmlgraphics.apache.org
Subject: Re: reference-orientation on side regions
On 07/03/11 23:57, Andreas Delmelle wrote:
>
> On 04 Mar 2011, at 12:25, Vincent Hennebert wrote:
>
>> On 03/03/11 20:18, Andreas Delmelle wrote:
>>>
>>> Let's assume that this refers to the default/normal situation. After all, we are quoting the _general_ fo:region-before definition (= where no deviating reference-orientation has been specified on the region). I would not believe anyone claiming that this definition was written with the intention of covering all possible combinations of reference-orientation/writing-mode.
>>
>> I’m not sure I’m following. The specification is supposed to cover all
>> cases, isnt’it?
>
> Yes, the specification as a whole, but a general definition of a formatting object is just that. It describes the regular behavior. In case the properties default to their initial values, and some such. To get the full picture of the possible effects of reference-orientation and writing-mode, the property definitions are just as important, if not more so.
>
>>> The general definition just states the normal behavior: if no deviating reference-orientation has been specified, the region-reference-area will have the same orientation as the viewport.
>>>
>>> The definition of reference-orientation (7.21.3) states that a value of '90' means that "the reference-orientation of this *reference-area* is rotated 90 degrees counter-clockwise from the reference-orientation of the *containing reference-area*."
>>
>> Exactly. So the reference-orientation of the region-viewport-area is
>> rotated from the reference-orientation of the page-reference-area.
>
> The reference-orientation of the region-reference-area is rotated with respect to the containing page-reference-area. Where does it say 'viewport'?
A viewport-area /is/ a reference-area. See section 4.2.2.
>>> So, specifying reference-orientation="90" on the region rotates its reference-area by 90 degrees from the page-reference-area. Nothing is said about the viewport here, mind you.
>>
>> There is, see Section 6.4.15, “fo:region-before”:
>> “The reference-orientation and writing-mode of the
>> region-viewport-area are determined by the formatting object that
>> generates the area (see 6.4.5 fo:page-sequence).”
>
> By 'here', I meant the definition of the property value.
> On the other hand: indeed! My point exactly. The reference-orientation of the region-viewport-area is always the same as that of the page-reference-area. Only the reference-orientation of the region-reference-area can deviate further (as described, by combining reference-orientation on the region with from-page-master-region() on the page-sequence). The new, rotated co-ordinate system would hold only *inside* the region-viewport-area to determine the dimensions and placement of the region-reference-area. On the outside, "before" is not rotated, yet.
I am getting a little impatient because the above is in clear
contradiction with what is written in the spec. The topic is already
complex, I think it’s important to not add to the confusion by making
sure we are reading it properly. Would you mind backing your points with
references to the spec?
If we take the XSL-FO example I put in my first message:
• from Section 6.4.13, “fo:simple-page-master”
“[The] reference-orientation [of the page-viewport-area]
is set to ‘0’”
“The reference-orientation of the page-reference-area [...] [is]
determined by the [...] fo:page-sequence.”
So the page-viewport-area has a reference-orientation of 0:
Top
Left Right
Bottom
And the page-reference-area has a reference-orientation of 90. As
explained in Section 7.21.3, “reference-orientation”, its
reference-orientation “is rotated 90 degrees counter-clockwise from
the reference-orientation of the [page-viewport-area]”:
R
T B
L
• from Section 6.4.15, “fo:region-before”:
“The reference-orientation [...] of the region-viewport-area [is]
determined by the [...] fo:page-sequence”
“The reference-orientation of the region-reference-area is set to
‘0’ and is, therefore, the same as the orientation established by
the region-viewport-area.”
So the reference-orientation of the region-viewport-area is rotated
90° counter-clockwise from the reference-orientation of the containing
reference-area, which is the page-reference-area (see section 6.4.5,
“fo:page-sequence”: “The region-viewport-area children of such
a page-reference-area...”):
B
R L
T
And, as explained in my first message, since the content-rectangle of
an area uses the reference-orientation of that area, the description
in Section 6.4.15 about how the content-rectangle should be positioned
appears to be inconsistent.
The reference-orientation of the region-reference-area is the same as
the one from the region-viewport-area:
B
R L
T
> Regards,
>
> Andreas
Thanks,
Vincent
-----------------------------------------
The information in this message may be proprietary and/or
confidential, and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient,
you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify First Data
immediately by replying to this message and deleting it from your
computer.
Re: reference-orientation on side regions
Posted by Vincent Hennebert <vh...@gmail.com>.
On 07/03/11 23:57, Andreas Delmelle wrote:
>
> On 04 Mar 2011, at 12:25, Vincent Hennebert wrote:
>
>> On 03/03/11 20:18, Andreas Delmelle wrote:
>>>
>>> Let's assume that this refers to the default/normal situation. After all, we are quoting the _general_ fo:region-before definition (= where no deviating reference-orientation has been specified on the region). I would not believe anyone claiming that this definition was written with the intention of covering all possible combinations of reference-orientation/writing-mode.
>>
>> I’m not sure I’m following. The specification is supposed to cover all
>> cases, isnt’it?
>
> Yes, the specification as a whole, but a general definition of a formatting object is just that. It describes the regular behavior. In case the properties default to their initial values, and some such. To get the full picture of the possible effects of reference-orientation and writing-mode, the property definitions are just as important, if not more so.
>
>>> The general definition just states the normal behavior: if no deviating reference-orientation has been specified, the region-reference-area will have the same orientation as the viewport.
>>>
>>> The definition of reference-orientation (7.21.3) states that a value of '90' means that "the reference-orientation of this *reference-area* is rotated 90 degrees counter-clockwise from the reference-orientation of the *containing reference-area*."
>>
>> Exactly. So the reference-orientation of the region-viewport-area is
>> rotated from the reference-orientation of the page-reference-area.
>
> The reference-orientation of the region-reference-area is rotated with respect to the containing page-reference-area. Where does it say 'viewport'?
A viewport-area /is/ a reference-area. See section 4.2.2.
>>> So, specifying reference-orientation="90" on the region rotates its reference-area by 90 degrees from the page-reference-area. Nothing is said about the viewport here, mind you.
>>
>> There is, see Section 6.4.15, “fo:region-before”:
>> “The reference-orientation and writing-mode of the
>> region-viewport-area are determined by the formatting object that
>> generates the area (see 6.4.5 fo:page-sequence).”
>
> By 'here', I meant the definition of the property value.
> On the other hand: indeed! My point exactly. The reference-orientation of the region-viewport-area is always the same as that of the page-reference-area. Only the reference-orientation of the region-reference-area can deviate further (as described, by combining reference-orientation on the region with from-page-master-region() on the page-sequence). The new, rotated co-ordinate system would hold only *inside* the region-viewport-area to determine the dimensions and placement of the region-reference-area. On the outside, "before" is not rotated, yet.
I am getting a little impatient because the above is in clear
contradiction with what is written in the spec. The topic is already
complex, I think it’s important to not add to the confusion by making
sure we are reading it properly. Would you mind backing your points with
references to the spec?
If we take the XSL-FO example I put in my first message:
• from Section 6.4.13, “fo:simple-page-master”
“[The] reference-orientation [of the page-viewport-area]
is set to ‘0’”
“The reference-orientation of the page-reference-area [...] [is]
determined by the [...] fo:page-sequence.”
So the page-viewport-area has a reference-orientation of 0:
Top
Left Right
Bottom
And the page-reference-area has a reference-orientation of 90. As
explained in Section 7.21.3, “reference-orientation”, its
reference-orientation “is rotated 90 degrees counter-clockwise from
the reference-orientation of the [page-viewport-area]”:
R
T B
L
• from Section 6.4.15, “fo:region-before”:
“The reference-orientation [...] of the region-viewport-area [is]
determined by the [...] fo:page-sequence”
“The reference-orientation of the region-reference-area is set to
‘0’ and is, therefore, the same as the orientation established by
the region-viewport-area.”
So the reference-orientation of the region-viewport-area is rotated
90° counter-clockwise from the reference-orientation of the containing
reference-area, which is the page-reference-area (see section 6.4.5,
“fo:page-sequence”: “The region-viewport-area children of such
a page-reference-area...”):
B
R L
T
And, as explained in my first message, since the content-rectangle of
an area uses the reference-orientation of that area, the description
in Section 6.4.15 about how the content-rectangle should be positioned
appears to be inconsistent.
The reference-orientation of the region-reference-area is the same as
the one from the region-viewport-area:
B
R L
T
> Regards,
>
> Andreas
Thanks,
Vincent
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 04 Mar 2011, at 12:25, Vincent Hennebert wrote:
> On 03/03/11 20:18, Andreas Delmelle wrote:
>>
>> Let's assume that this refers to the default/normal situation. After all, we are quoting the _general_ fo:region-before definition (= where no deviating reference-orientation has been specified on the region). I would not believe anyone claiming that this definition was written with the intention of covering all possible combinations of reference-orientation/writing-mode.
>
> I’m not sure I’m following. The specification is supposed to cover all
> cases, isnt’it?
Yes, the specification as a whole, but a general definition of a formatting object is just that. It describes the regular behavior. In case the properties default to their initial values, and some such. To get the full picture of the possible effects of reference-orientation and writing-mode, the property definitions are just as important, if not more so.
>> The general definition just states the normal behavior: if no deviating reference-orientation has been specified, the region-reference-area will have the same orientation as the viewport.
>>
>> The definition of reference-orientation (7.21.3) states that a value of '90' means that "the reference-orientation of this *reference-area* is rotated 90 degrees counter-clockwise from the reference-orientation of the *containing reference-area*."
>
> Exactly. So the reference-orientation of the region-viewport-area is
> rotated from the reference-orientation of the page-reference-area.
The reference-orientation of the region-reference-area is rotated with respect to the containing page-reference-area. Where does it say 'viewport'?
>> So, specifying reference-orientation="90" on the region rotates its reference-area by 90 degrees from the page-reference-area. Nothing is said about the viewport here, mind you.
>
> There is, see Section 6.4.15, “fo:region-before”:
> “The reference-orientation and writing-mode of the
> region-viewport-area are determined by the formatting object that
> generates the area (see 6.4.5 fo:page-sequence).”
By 'here', I meant the definition of the property value.
On the other hand: indeed! My point exactly. The reference-orientation of the region-viewport-area is always the same as that of the page-reference-area. Only the reference-orientation of the region-reference-area can deviate further (as described, by combining reference-orientation on the region with from-page-master-region() on the page-sequence). The new, rotated co-ordinate system would hold only *inside* the region-viewport-area to determine the dimensions and placement of the region-reference-area. On the outside, "before" is not rotated, yet.
Regards,
Andreas
---
Re: reference-orientation on side regions
Posted by Vincent Hennebert <vh...@gmail.com>.
On 03/03/11 20:18, Andreas Delmelle wrote:
> On 03 Mar 2011, at 13:08, Vincent Hennebert wrote:
>
>>> 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...
>>
>> See the following sentence in Section 6.4.15, “fo:region-before”:
>> “The reference-orientation and writing-mode of the
>> region-viewport-area are determined by the formatting object that
>> generates the area (see 6.4.5 fo:page-sequence). The
>> reference-orientation of the region-reference-area is set to "0" and
>> is, therefore, the same as the orientation established by the
>> region-viewport-area. The writing-mode of the region-reference-area
>> is set to the same value as that of the region-viewport-area.”
>>
>> So the region-reference-area has the same orientation as the
>> page-viewport-area.
>
> Let's assume that this refers to the default/normal situation. After all, we are quoting the _general_ fo:region-before definition (= where no deviating reference-orientation has been specified on the region). I would not believe anyone claiming that this definition was written with the intention of covering all possible combinations of reference-orientation/writing-mode.
I’m not sure I’m following. The specification is supposed to cover all
cases, isnt’it?
> The general definition just states the normal behavior: if no deviating reference-orientation has been specified, the region-reference-area will have the same orientation as the viewport.
>
> The definition of reference-orientation (7.21.3) states that a value of '90' means that "the reference-orientation of this *reference-area* is rotated 90 degrees counter-clockwise from the reference-orientation of the *containing reference-area*."
Exactly. So the reference-orientation of the region-viewport-area is
rotated from the reference-orientation of the page-reference-area.
> So, specifying reference-orientation="90" on the region rotates its reference-area by 90 degrees from the page-reference-area. Nothing is said about the viewport here, mind you.
There is, see Section 6.4.15, “fo:region-before”:
“The reference-orientation and writing-mode of the
region-viewport-area are determined by the formatting object that
generates the area (see 6.4.5 fo:page-sequence).”
> It is in the viewport that a new coordinate system is established, not 'around' it, so to speak. The before-edge still remains in parallel with the page-reference-area's before-edge, when looking at it from the parent.
> Inside the viewport, before/after/start/end get different meanings, for the placement/dimensions of the child (reference-area).
I’m a bit puzzled. Did you see this paragraph from my first message?
“[...] Because, as explained in Section 4.2.3, “Geometric
Definitions”, the definition of the before/after/start/end-edges of
the content-rectangle of an area uses the
inline/block-progression-direction of that area; Whereas the
border/padding/allocation-rectangles use the directions of the
parent area.”
> Regards,
>
> Andreas
> ---
Thanks,
Vincent
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 03 Mar 2011, at 13:08, Vincent Hennebert wrote:
>> 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...
>
> See the following sentence in Section 6.4.15, “fo:region-before”:
> “The reference-orientation and writing-mode of the
> region-viewport-area are determined by the formatting object that
> generates the area (see 6.4.5 fo:page-sequence). The
> reference-orientation of the region-reference-area is set to "0" and
> is, therefore, the same as the orientation established by the
> region-viewport-area. The writing-mode of the region-reference-area
> is set to the same value as that of the region-viewport-area.”
>
> So the region-reference-area has the same orientation as the
> page-viewport-area.
Let's assume that this refers to the default/normal situation. After all, we are quoting the _general_ fo:region-before definition (= where no deviating reference-orientation has been specified on the region). I would not believe anyone claiming that this definition was written with the intention of covering all possible combinations of reference-orientation/writing-mode.
The general definition just states the normal behavior: if no deviating reference-orientation has been specified, the region-reference-area will have the same orientation as the viewport.
The definition of reference-orientation (7.21.3) states that a value of '90' means that "the reference-orientation of this *reference-area* is rotated 90 degrees counter-clockwise from the reference-orientation of the *containing reference-area*."
So, specifying reference-orientation="90" on the region rotates its reference-area by 90 degrees from the page-reference-area. Nothing is said about the viewport here, mind you.
It is in the viewport that a new coordinate system is established, not 'around' it, so to speak. The before-edge still remains in parallel with the page-reference-area's before-edge, when looking at it from the parent.
Inside the viewport, before/after/start/end get different meanings, for the placement/dimensions of the child (reference-area).
Regards,
Andreas
---
Re: reference-orientation on side regions
Posted by Vincent Hennebert <vh...@gmail.com>.
On 02/03/11 21:30, Andreas Delmelle wrote:
> On 02 Mar 2011, at 21:30, Vincent Hennebert wrote:
<snip/>
>> 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 see. I thought that was an oversight in FOPropertyMapping.
<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...
See the following sentence in Section 6.4.15, “fo:region-before”:
“The reference-orientation and writing-mode of the
region-viewport-area are determined by the formatting object that
generates the area (see 6.4.5 fo:page-sequence). The
reference-orientation of the region-reference-area is set to "0" and
is, therefore, the same as the orientation established by the
region-viewport-area. The writing-mode of the region-reference-area
is set to the same value as that of the region-viewport-area.”
So the region-reference-area has the same orientation as the
page-viewport-area.
> 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
Frankly, I’m not willing to look at the XSL-FO 1.0 Recommendation.
I don’t have the energy to understand the logic that’s explained there,
understanding one version is already hard enough. But, most of all,
I don’t want to have two versions loaded in my head at the same time.
I would completely confuse things between the two. It’s already easy
enough to make confusions with just one version.
Thanks,
Vincent
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
On 02 Mar 2011, at 22:30, Andreas Delmelle wrote:
> <snip />
> The implementation of the (from-page-master) 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)
Reconsidering that, this may have been a bit too quick, but only a bit:
Obviously, the result of the function call can only be known at parse-time in a limited set of cases. Not so difficult for the side-regions, though, as the static-contents are generally mapped to very specific region-references. That is just a property lookup in the FO tree.
For flow descendants, if the flow is just generically mapped to 'xsl-region-body' (= the only option FOP currently supports) it may be significantly harder to solve, since it is only known much, much later which page-master will actually be used, and hence which exact region-body needs to be looked at.
Regards,
Andreas
---
Re: reference-orientation on side regions
Posted by Andreas Delmelle <an...@telenet.be>.
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
---