Cart
[Home] [By Thread] [By Date] [Recent Entries]
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: 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: 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. ... 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 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@xxxxxxxxxxxxxxxxxxxx Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal
|
