Re: recto page with blank back

jmacneilly@comcast.net wrote on 12.04.2004 19:18:05:

> I come from the FOSI world (where this is possible) and military 
> applications (where this is required) and need to be able to set up 
> an XSL-FO application with the following condition output on an odd 
> page: page 43/44 blank. I am ending each chapter/work package on an 
> even page, which sometimes may be blank.
> 
> Does the current spec support this? If so, can you tell me how. (I 
> have not been able to set this up successfully, although I have 
> blank pages working.) Or are there any plans for this feature? Is 
> it/will it be supported by vendors? I found the thread below on the 
> Yahoo XSL-FO group, and know this is a big requirement for Army and 
> Navy tech manuals. Any information will be greatly appreciated.
.....
> > But I hope the XSL committee is listening or you can take the time to 
send
> > your requirement to the xsl-editors@w... address. I think you've made 
a
> > justification for a "next-to-last" page-position test value (though 
not
> > being an implementer I'm not sure what the ramifications are). Wait 
...
> > even that won't help, because just with that you won't be able to say
> > "next-to-last when last-is-blank", so it is getting too bizarre to try 
and
> > express declaratively.

Joy,

I think that:

1. The current spec doesn't support this - for the reasons outlined in 
your quotes. One could think of a hack concerning inserting pseudo-blank 
pages at the start of a chapter instead of at the end, but this gets 
really ugly - if it works at all.

2. My suggestion for the XSL committee would be to add support for this 
functionality by specifying two new functions: page-number and 
page-number-citation with the same semantics as in the fo:page-number and 
fo:page-number-citation elements. Also, we would need a next-to-last 
option for the page-position property (in that case you could have a 
special page-master for page-position="next-to-last" and 
odd-or-even="odd").

I don't see the mentioned issue about '"next-to-last when last-is-blank"' 
since "odd-or-even=odd" already does that for you in your case. One more 
thing: a "value" property for fo:page-number so you can specify things 
like "<fo:page-number ...other formatting options.... 
value="page-number()+1"/>

I just tried it in our XSL-formatter - it's pretty easy to add if the 
"last" test value is already implemented (ok, make that 'reasonably 
implemented'), and it's also fairly straightforward to specify formally. 

XSL-Editors: how about that for XSL 1.1?

Hope this helps,

Arnd Beissner
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99
Mobile: +49-173-3016917






xsl-editors-request@w3.org wrote on 12.04.2004 19:18:05:

> I come from the FOSI world (where this is possible) and military 
> applications (where this is required) and need to be able to set up 
> an XSL-FO application with the following condition output on an odd 
> page: page 43/44 blank. I am ending each chapter/work package on an 
> even page, which sometimes may be blank.
> 
> Does the current spec support this? If so, can you tell me how. (I 
> have not been able to set this up successfully, although I have 
> blank pages working.) Or are there any plans for this feature? Is 
> it/will it be supported by vendors? I found the thread below on the 
> Yahoo XSL-FO group, and know this is a big requirement for Army and 
> Navy tech manuals. Any information will be greatly appreciated.
> 
> Joy MacNeilly
> PBM Associates, Inc.
> joy@pbmassoc.com
> 
> 
> 
> 
> From:  "G. Ken Holman" <gkholman@c...> 
> Date:  Thu Feb 5, 2004  10:48 pm
> Subject:  Re: [XSL-FO] Reverse Blank page numbering

> 
> At 2004-02-05 15:03 -0500, Gina Cicotello wrote:
> >My question is about page numbering, which appears in the footer. Our 
style
> >guide says the last page of content, if an odd page, needs to have 
special
> >page numbering, thus:
> >
> >The chapter content ends on page 75. The footer on page 75 says "75/(76
> >blank)".
> 
> You can't do the "(76 blank)" bit because you cannot calculate using 
page
> numbers.
> 
> >In other parts of the manual (frontmatter and rearmatter), the same 
scenario
> >is treated with "75 (Reverse Blank)". Obviously, I'll create several
> >footers.
> 
> I've just tried using a combination of page-position="last" and
> odd-or-even="odd" to give you what you want, but the
> force-page-count="even" makes the even blank page the last page of the 
page
> sequence (I had mistakenly thought the content page would be considered 
the
> last page of the page sequence) so the condition is never considered 
true.
> 
> On closer examination of the spec, I see in 7.25.6 that any forced page 
at
> the end becomes the "last" page in the sequence for the purposes of 
testing
> page position ... so it is, indeed, not possible to test for 
"next-to-last"
> page in the page sequence.
> 
> But I hope the XSL committee is listening or you can take the time to 
send
> your requirement to the xsl-editors@w... address. I think you've made a
> justification for a "next-to-last" page-position test value (though not
> being an implementer I'm not sure what the ramifications are). Wait ...
> even that won't help, because just with that you won't be able to say
> "next-to-last when last-is-blank", so it is getting too bizarre to try 
and
> express declaratively.
> 
> So in summary I think you are out of luck and there may not be a concise
> addition to propose to the committee for consideration.
> 
> >So I need a conditional that determines when the content ends on an odd
> >page,
> 
> Because conditions are processed at transformation time, and your
> requirement is only known at formatting time, there is nothing in 1.0 
that
> can help you.
> 
> >and a way to calculate the next (even) page number.
> 
> Nope ... no calculations can be done on page numbers.
> 
> >This can't be that uncommon.
> 
> Unfortunately there are many "common" requirements that just couldn't be
> met with XSL-FO 1.0 that will be addressed in future versions. I
> understand that had the committee tried to add everything in the first
> version, it would never have been released due to feature creep. The 
first
> version was necessary to understand how it was going to be used.
> 
> ........................... Ken

> 
>

Received on Tuesday, 13 April 2004 05:36:29 UTC