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

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

Expand Messages
  • G. Ken Holman
    ... 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
    Message 1 of 7 , Feb 1, 2007
    • 0 Attachment
      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@...
      Crane Softwrights Ltd. 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
      Legal business disclaimers: http://www.CraneSoftwrights.com/legal
    • J.Pietschmann
      ... Probably because of the common misunderstanding that the FO statements are evaluated , i.e. that markers are actually retrieved during the XSL
      Message 2 of 7 , Feb 1, 2007
      • 0 Attachment
        G. Ken Holman wrote:
        >> <xsl:variable name="first" as="xs:string">
        >> <fo:retrieve-marker retrieve-class-name="header"
        >> retrieve-boundary="page" retrieve-position="first-including-carryover"/>
        >> </xsl:variable>
        ...
        > 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?

        Probably because of the common misunderstanding that the FO "statements"
        are "evaluated", i.e. that markers are actually retrieved during the XSL
        transformation.

        J.Pietschmann
      • 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 3 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.