W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2004

RE: recto page with blank back

From: Paul Grosso <pgrosso@arbortext.com>
Date: Fri, 15 Oct 2004 16:06:30 -0400
Message-ID: <F13E1BF26B19BA40AF3C0DE7D4DA0C03F42944@ati-mail01.arbortext.local>
To: <arnd.beissner@cappelino.de>, <xsl-editors@w3.org>

Arnd,

Thank you for your interest in XSL FO.

The XSL FO SubGroup discussed your email requesting new 
functionality to allow for a solution to "page with blank 
back" problem.

Several SG members think what your are suggesting is 
basically equivalent to asking for the resolved value 
of things like page numbers to be available to the XSL 
FO expression language.  But the expression language is 
expected to be evaluated before page generation, so it is
not possible to have page numbers available at expression
language evaluation time.  Certainly, even if there were
certain tricks some implementations could do to get this
information (such as a multiple pass method) we would not
want to write something that requires a certain kind of
implementation trick into the specification.

The XSL FO SG has decided not to add such an enhancement
into XSL 1.1.

Paul Grosso
for the W3C XSL FO SG


> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of 
> arnd.beissner@cappelino.de
> Sent: Tuesday, 13 April, 2004 4:31
> To: xsl-editors@w3.org
> Subject: 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 Friday, 15 October 2004 20:08:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:48 UTC