Loading ...
Sorry, an error occurred while loading the content.

Re: [XSL-FO] Problem with Dictionary Style Running Heads

Expand Messages
  • Jeff Sese
    It s not that i don t want to try your sample code... (it was near end of office hours so i was planning to try it this morning) I just want confirmation or at
    Message 1 of 7 , Feb 1, 2007
    • 0 Attachment
      It's not that i don't want to try your sample code... (it was near end
      of office hours so i was planning to try it this morning) I just want
      confirmation or at least some insights that my assumptions of the sample
      code, given a data somewhat the same as the one presented below, were
      correct or wrong.

      After trying the code this morning, i did confirm that indeed that my
      assumptions were correct. That if i have a page that would contain one
      article, then the resulting header using:
      <block>
      <retrieve-marker retrieve-class-name="header-start"
      retrieve-boundary="page" retrieve-position="first-including-carryover"/>
      <retrieve-marker retrieve-class-name="header-end"
      retrieve-boundary="page" retrieve-position="last-starting-within-page"/>
      </block>
      would be: title1 - title1; which is not my desired output.

      The code i posted below was written after i posted my first post, and I
      thought that I had the correct output but after looking at it this
      morning it was not (proof that I really needed to go home at that time
      :)). I just tried that code thinking that the fo:retrieve-marker would
      return a value in xslt... which i was wrong.

      Is there any work-around to this problem? Btw i'm using an evaluation
      software of Antenna XSL-Formatter.

      Thanks for the help,
      *Jeff Sese*

      G. Ken Holman wrote:
      >
      > At 2007-02-01 17:02 +0800, Jeff Sese wrote:
      > >Ken, I haven't tried your code yet but i think if i have a page like
      > this:
      >
      > Well, I don't have the time to make *more* test data for your
      > requirements, so if you haven't tried the code I took the time to
      > suggest then I won't bother trying it either.
      >
      > >I tried this and i got the desired output,
      >
      > Then why did you post in your first message that you had a problem?
      >
      > >but i can seem to understand how it happened.
      >
      > I do not see why you have added complexity in your code.
      >
      > ><xsl:variable name="first" as="xs:string">
      > > <fo:retrieve-marker retrieve-class-name="header"
      > >retrieve-boundary="page" retrieve-position="first-including-carryover"/>
      > ></xsl:variable>
      > ><xsl:variable name="last" as="xs:string">
      > > <fo:retrieve-marker retrieve-class-name="header"
      > >retrieve-boundary="page" retrieve-position="last-starting-within-page"/>
      > ></xsl:variable>
      > ><fo:block>
      > > <xsl:choose>
      > > <xsl:when test="$first eq $last">
      >
      > You have bound two specified sequence constructors to variables as
      > strings and then compared them. Each string is empty. They will
      > always return the same result and will be considered equal. How did
      > you think they were going to vary?
      >
      > >I tried outputting the content of the variable using xsl:message but i
      > >get no output for their value:
      > ><xsl:message>
      > > <xsl:copy-of select="$first"/>
      > > <xsl:copy-of select="$last"/>
      > ></xsl:message>
      >
      > Both variables are cast as strings and they are both empty, hence you
      > get their empty value.
      >
      > >Is my xslt above correct?
      >
      > "correct" for what purpose? It does seem nonsensical to cast empty
      > string values and then compare them.
      >
      > >It does give me the desired output though...
      >
      > Well, I cannot see how, since your comparison of two empty strings
      > will always produce a "true" and you won't see the dash. But since
      > you are seeing the dash, then I don't understand where you got your
      > snippet, or some other information is missing.
      >
      > Remember that the XSL-FO process is arms-length from the XSLT
      > process. There is no feedback loop. There is *nothing* you can test
      > in your XSLT that is the result of any condition of formatting in your
      > XSL-FO.
      >
      > . . . . . . . . . . . . . Ken
      >
      > --
      > World-wide corporate, govt. & user group XML, XSL and UBL training
      > RSS feeds: publicly-available developer resources and training
      > G. Ken Holman mailto:gkholman@...
      > <mailto:gkholman%40CraneSoftwrights.com>
      > Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
      > <http://www.CraneSoftwrights.com/f/>
      > Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
      > Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/f/bc
      > <http://www.CraneSoftwrights.com/f/bc>
      > Legal business disclaimers: http://www.CraneSoftwrights.com/legal
      > <http://www.CraneSoftwrights.com/legal>
      >
      >
      > ------------------------------------------------------------------------
      >
      > No virus found in this incoming message.
      > Checked by AVG Free Edition.
      > Version: 7.5.432 / Virus Database: 268.17.18/662 - Release Date: 1/31/2007 3:16 PM
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.