W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2004

recto page with blank back

From: Joy MacNeilly <jmacneilly@comcast.net>
Date: Mon, 12 Apr 2004 13:18:05 -0400
Message-ID: <007401c420b2$1e66d620$2f2e9318@PBMVZHDRZZTM16>
To: <xsl-editors@w3.org>
Cc: "Larry Howard" <larryh@ark-const.com>, <gkholman@CraneSoftwrights.com>
Hi,

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 Monday, 12 April 2004 13:22:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:57 GMT