At 2012-06-11 11:55 -0700, Underwood Michelle wrote:
>Unrelated to your question, for performance reasons on some
>processors you might wish to review your use of "//" in the following:
These are part of the generated code in the GUI development
environment and I can't change them.
Ouch! How unfortunate. While there certainly are important
use-cases where "//" is the best way to get what you need, it is
unfortunate to see this construct abused in situations where it isn't
necessary. I'm not saying this is one of those times ... it just
seems "lazy" to use it where it isn't appropriate, and for some
processors it may be expensive.
I think the error message is because I 'hard-coded' that choose in
there instead of using the GUI interface and the program doesn't like it.
Not every feels as I do, but I've never trusted any GUI to write XSLT
the way I would like XSLT to be written. Some say that is simply my
bias for my teaching.
Or, it could be that you can't nest choose statements. I'm not sure which.
One can certainly properly nest choose statements ... they have no
contextual restriction (beyond typical top-level constraints). Just
remember that <xsl:choose> can only have <xsl:when> and
<xsl:otherwise> and those two constructs can only have <xsl:choose>
as their parent.
My question is, why not as long as the referenced page number is
generated before the referencing page? Is the value of the initial
page number evaluated at transform or render?
Just the way the semantics were dictated by the designers of XSL-FO.
I understand that the xslt processing happens at a different time
than the xsl:fo processing (transform vs render) but I'm looking for
a way to tell the renderer which initial page number to use based on
the outcome of the xsl:choose so that the renderer either uses
"auto" or looks at the page number of the referenced fo:block id to
determine the starting page number of the next section if there is a
blank page inserted between them.
Not in as many words, but I feel there must be a way to get what you
need with the existing semantics.
Likewise, there must be a way to change the page force based on the
outcome of the transform such as whether or not there is any content
in Section 2.
Certainly there is ... you change the behaviour of page numbering
using XSL-FO semantics based on the XSLT determination of "the
presence of section 2" however you determine that.
Here is the Use Case (or requirement statement), setup, and examples:
I need a single output file that contains 2 or 3 sections having a
common, continuous page numbering where Section 1 must have an
initial page number of 1, start-on-odd, and, unless the optional
Section 2 exists, end-on-even, but if Section 2 exists then Section
1 and 2 must be continuous without blank pages between them and, in
regards to page number and ending page force, become one Section,
but because they may have slightly different footer content they
must each have a separate static fo:block for the region-after, and
when put together they must end-on-even so that Section 3 physically
begins on an separate piece of paper when printed in duplex mode and
will end-on-even, even if the logical page numbering says that this
is an odd numbered page because the page numbering must logically
start with the next page number that follows the end of Section 1-2
regardless of whether a blank page is inserted before it causing
there to be a difference between the physical page number and the
logic page number.
Sounds like you may be unaware of force-page-count="no-force", which
is not the default.
So, for the first page-sequence (if using XSLT 2):
initial-page-count="1"
force-page-count="{ if ( {your-test-for-section-2-exists} )
then 'no-force' else 'end-on-even' }"
For the second section page sequence:
force-page-count="end-on-even"
... so that the third section starts on the odd page number.
But note that if a blank even page is generated it's page number
cannot be skipped in the sequence ... the last page with content in
section two would have an odd page number and the first page of
section three would have the next odd page number.
You can turn blank-page generation off with "no-force" but you cannot
exclude blank-page generation from page-number counting.
Just the way it works.
I am attempting to dynamically set the starting page numbers so that
the "Page # of [total]" on each page accurately reflects only those
pages which have content.
Using XSL-FO 1.1 you can cite the last page number of any section or
of the document ... but it isn't a count of "pages with content", it
is simply a count of pages. You can skip the very last if it is a
blank, but you can't skip a middle page between sequences if it is a blank.
But with force-page-count="no-force", there are no middle blank pages.
Here is what I am doing to attempt this:
Thanks for spelling it all out.
...
In other words, If Section 2 is included, Sections 1 and 2 flow
together when printed in duplex (both sides of the paper) and insert
only one blank page, if needed, that falls between them and Section
3, so that Section 3 starts on the front of the page,
That is what I wrote out up above.
but continue the same page numbering without counting that blank page.
That is something currently not available in XSL-FO. You just cannot
request that.
But for duplex printing, I'm surprised you want continuous page
numbering not including blank pages because that would put even page
numbers on the "right hand side" of a bound set of folios. Which is
not typical (and I find jarring when I've found it in newbie publications).
Section 1 = odd
Section 2 = none
Section 3 = even
Section 1 pages are numbered Page 1 of 7, through 5 of 7.
Physical page 6 is a blank page that is not included in the total page count.
Section 3 pages are numbered Page 6 of 7 through 7 of 7, as
physical page 8, and there is no blank page at the end.
Nope ... no can do with XSL-FO 1.1 ... blank pages participate in
page numbering.
P.S. I hope I did this reply correctly so that it posts to the
correct thread. This is my first time using an email chain forum.
Nope ... it looks like you broke the chain. In MarkMail the old chain is here:
http://markmail.org/message/hc2sp2zi6jxesbkh
... and this message seems to be in a new chain:
http://markmail.org/message/c44jlh75jllvc5an
When I replied to your original message I did a "reply all", as I am
doing with this message, and we'll see if this gets added to the second chain.
I hope this has been helpful (even if it doesn't give you a
"standard" way out of your predicament).
. . . . . . . . . . . Ken
--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--