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

Re: [XSL-FO] line-height of a basic-link around an

Expand Messages
  • David Tolpin
    ... And does it wrong. That was behaivour implemented in an early version of XEP for inlines and changed later to a conformant one. basic-link is an inline.
    Message 1 of 17 , Aug 11 3:52 AM
    • 0 Attachment
      >
      > At 2002-08-09 19:57 +0000, cramerdw wrote:
      > >Given this fo:
      > >
      > ><fo:basic-link internal-destination="foo">
      > > <fo:external-graphic src="url(foo.gif)" content-width="auto"
      > > content-height="auto"/>
      > ></fo:basic-link>
      > >
      > >In the resulting pdf, only the very bottom edge of the image is hot: the
      > >height of one line.
      >
      > This sounds like a bug in your implementation ... Antenna House makes the
      > entire image hot.

      And does it wrong. That was behaivour implemented in an early version of XEP
      for inlines and changed later to a conformant one.

      basic-link is an inline. The area's height (block-progression-dimension)
      is determined by line-height treat of the inline itself, not
      by the contents.

      This may be strange sometimes, but this is consistent and logical after
      a closer examination.

      David Tolpin
      RenderX
    • Nikolai Grigoriev
      Hi Ken, let me explain XEP s interpretation of the basic-links. Our idea is straightforward: the hot area corresponds to the border-rectangle of the basic-link
      Message 2 of 17 , Aug 11 4:08 PM
      • 0 Attachment
        Hi Ken,

        let me explain XEP's interpretation of the basic-links. Our idea is
        straightforward: the hot area corresponds to the border-rectangle
        of the basic-link inline area. When you specify a border around
        the fo:basic-link, the zone inside the border becomes hot, and the
        outside remains inactive. Natural, isn't it?

        > Okay ... section 4.6 talks about the content rectangle in terms of the text
        > dimension ... but I would have thought the large allocation rectangle of
        > the graphic would have increased the height of the content rectangle.

        Unfortunately, the spec prescribes otherwise. Let's look at [4.6. Inline-areas]:

        XSL> An inline-area with inline-area children has a content-rectangle
        XSL> which extends from its dominant baseline ... by its text-depth in
        XSL> the block-progression-direction, and in the opposite direction
        XSL> by its text-altitude.

        Ergo: the content rectangle of a typical inline _does not depend on
        its contents_. Only font attributes matter, plus eventual redefinitions
        of text-depth or text-altitude. This applies to fo:basic-link, too.

        > ... after all, if I border a graphic, the border goes around the whole
        > graphic and not just the line height), then the containing area would, I
        > thought, be well defined, thus would be "hot" to the hyperlink.

        This would be true if @external-destination were ascribed directly
        to the graphic. Unfortunately, fo:basic-link is another object that
        generates inline-areas of its own. If you set a border on it, it may
        cross a tall image located inside.

        The above serves to demonstrate that our decision was not casual :-).
        However, the problem is real - I concur that in David Cramer's case,
        XEP's behaviour is far from intuitive. Maybe we should ask authors
        of the XSL spec?

        Regards,
        Nikolai Grigoriev
        RenderX
      • G. Ken Holman
        ... Thanks for taking the time to do so. ... Yes, based on your premise the hot area corresponds to the border rectangle. ... I concede the allocation
        Message 3 of 17 , Aug 12 6:09 AM
        • 0 Attachment
          At 2002-08-12 03:08 +0400, Nikolai Grigoriev wrote:
          >let me explain XEP's interpretation of the basic-links.

          Thanks for taking the time to do so.

          >Our idea is
          >straightforward: the hot area corresponds to the border-rectangle
          >of the basic-link inline area. When you specify a border around
          >the fo:basic-link, the zone inside the border becomes hot, and the
          >outside remains inactive. Natural, isn't it?

          Yes, based on your premise the hot area corresponds to the border rectangle.

          > > Okay ... section 4.6 talks about the content rectangle in terms of the text
          > > dimension ... but I would have thought the large allocation rectangle of
          > > the graphic would have increased the height of the content rectangle.
          >
          >Unfortunately, the spec prescribes otherwise.

          I concede the allocation rectangle of the graphic does not increase the
          height of the content rectangle. I jumped to a conclusion based on my rush
          to write the note.

          >Let's look at [4.6. Inline-areas]:
          >
          >XSL> An inline-area with inline-area children has a content-rectangle
          >XSL> which extends from its dominant baseline ... by its text-depth in
          >XSL> the block-progression-direction, and in the opposite direction
          >XSL> by its text-altitude.
          >
          >Ergo: the content rectangle of a typical inline _does not depend on
          >its contents_. Only font attributes matter, plus eventual redefinitions
          >of text-depth or text-altitude. This applies to fo:basic-link, too.

          Granted ... the content rectangle does not change.

          > > ... after all, if I border a graphic, the border goes around the whole
          > > graphic and not just the line height), then the containing area would, I
          > > thought, be well defined, thus would be "hot" to the hyperlink.
          >
          >This would be true if @external-destination were ascribed directly
          >to the graphic. Unfortunately, fo:basic-link is another object that
          >generates inline-areas of its own. If you set a border on it, it may
          >cross a tall image located inside.

          Granted, the basic-link's block will cut through the image.

          At 2002-08-11 11:21 -0400, I wrote:
          >Also, 6.9.2 states "The object allows for traversal to the destination
          >resource, typically by clicking on any of the containing areas"
          >...
          >I've looked for a description of "containing area" and cannot find one
          >right away

          Perhaps, then, I was mistaken in my interpretation to think "containing
          area" means "area within the content rectangle". Perhaps "containing area"
          is in reference to the area tree, where a child area is "contained within"
          the parent area even if the dimensions are outside the parent area, and not
          in reference to the canvas where the content rectangle is defined.

          Accepting that the English language is not precise, I see in 4.7.2(4) the
          use of the phrase "... last area in the containing subset ..." which is in
          reference to the area tree and not the canvas. Other uses of the word
          "contain" are fairly obvious in other contexts, but this is an example of
          the word referring to containment of areas in the abstraction rather than
          the concrete real estate of the page itself.

          Following this logic, one could possibly interpret 6.9.2 as "by clicking on
          any of the areas contained by the basic-link area in the area tree, and all
          the real estate those areas occupy on the page".

          At 2002-08-12 03:08 +0400, Nikolai Grigoriev wrote:
          >The above serves to demonstrate that our decision was not casual :-).

          :{)} Nikolai, I have *never* thought implementation decisions were made
          casually and hope to not have given the impression your decision in this
          area was frivolous.

          >However, the problem is real - I concur that in David Cramer's case,
          >XEP's behaviour is far from intuitive. Maybe we should ask authors
          >of the XSL spec?

          I am interested to hear their response, as I am still of the mind there is
          an interpretation that can allow for the entire graphic to be hot.

          Thanks again for taking your time with this, Nikolai.

          ................... Ken


          --
          Upcoming hands-on in-depth 3-days XSLT/XPath and/or 2-days XSL-FO:
          - North America: Sep 30-Oct 4,2002
          - Japan: Oct 7-Oct 11,2002

          G. Ken Holman mailto:gkholman@...
          Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/
          Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
          ISBN 0-13-065196-6 Definitive XSLT and XPath
          ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
          ISBN 1-894049-07-1 Practical Formatting Using XSLFO
          XSL/XML/DSSSL/SGML/OmniMark services, books (electronic, printed),
          articles, training (instructor-live,Internet-live,web/CD,licensed)
          Next public training: 2002-08-05,26,27,09-30,10-03,07,10
        • bryan
          ... is ... It would also be in keeping with the type of links that most people would be familiar with, i.e hyperlinking in html. It would be compatible with
          Message 4 of 17 , Aug 12 7:01 AM
          • 0 Attachment
            >>However, the problem is real - I concur that in David Cramer's case,
            >>XEP's behaviour is far from intuitive. Maybe we should ask authors
            >>of the XSL spec?

            >I am interested to hear their response, as I am still of the mind there
            is
            >an interpretation that can allow for the entire graphic to be hot.

            It would also be in keeping with the type of links that most people
            would be familiar with, i.e hyperlinking in html.
            It would be compatible with simple XLink.

            I have a hard time seeing how it would be a useful feature that links
            behaved in this manner, unless it were for the purpose of defining
            hotspots for images, which could be achieved via other ways - although
            granted each one that I can think of would have an ugly hack feel to
            them.
            If anyone can think of how such behavior would be a useful feature
            please explain.

            At any rate given
            http://www.w3.org/TR/xsl/slice1.html#section-N1044-Linking refers to
            html linking for formatting of a link, and XLink for the semantics of
            following a link, and given(if indeed you would give this) that the
            section above seems to be an abstract description of intended meaning of
            what linking is in XSL-FO then I think Ken is right here.
          • David Tolpin
            Ken et al, this problem is not the only one in the current Recommendation. The fact that common sense contradicts with the word of the document should not draw
            Message 5 of 17 , Aug 12 2:45 PM
            • 0 Attachment
              Ken et al,

              this problem is not the only one in the current Recommendation.

              The fact that common sense contradicts with the word of the document
              should not draw implementors from following the XSL FO Recommendation;
              the path of common sense leads to troubles way mor often than it seems
              it does.

              If the spec means that basic-link should propagate hot areas to all
              _contained_ areas, not just to _containing_ ones, then it should
              be worded as such, namely, that

              - both internal-destination and external-destination are inheritable
              - they apply to all elements generating normal inline or block-level
              areas
              - they by themselves turn the areas into link anchors.

              Then fo:basic-link wouldn't be required for any but purely cosmetical purpose
              and the behaviour that lives in agreement with common sense would become
              natural.

              Right now, however, the recommendation is clear in that respect: basic-link
              is the element to form an anchor; and hot areas are containing areas generated
              by the element.

              David
            • David Tolpin
              As a followup, I would like to admit that although XSL FO Recommendation can and probably should be improved; almost every case where common sense is in
              Message 6 of 17 , Aug 12 3:22 PM
              • 0 Attachment
                As a followup,

                I would like to admit that although XSL FO Recommendation can and probably should
                be improved; almost every case where common sense is in contradiction with the
                recommended behaviour, the latter turns out to be more consistent and logical
                at closer investigation.

                Consider a case when a basic-link with internal-destination is nested
                within a basic-link with external-destination. If the anchor is built
                of all descendant areas, then where should the link attached to descendants
                of the innermost basic-link point to?

                Should it point just to external-destination? Or to both external and internal?

                Where in the recommendation is it described?

                It seems to me that the least contradictory approach is one chosen
                by the recommendation, that is that the link is attached to the
                area generated by a basic-link element. It permits a comprehendable implementation
                in general case. I don't see how other approaches can be clearly expressed within
                the current logic of XSL FO.

                David Tolpin
              • G. Ken Holman
                ... Yet some implementations choose to not do property inheritance through certain constructs, such as footnotes, which I understand the specification
                Message 7 of 17 , Aug 23 12:58 PM
                • 0 Attachment
                  At 2002-08-13 01:45 +0500, David Tolpin wrote:
                  >this problem is not the only one in the current Recommendation.
                  >
                  >The fact that common sense contradicts with the word of the document
                  >should not draw implementors from following the XSL FO Recommendation;
                  >the path of common sense leads to troubles way mor often than it seems
                  >it does.

                  Yet some implementations choose to not do property inheritance "through"
                  certain constructs, such as footnotes, which I understand the specification
                  requires.

                  For example, if I have a footnote in an indented block, then the blocks of
                  the footnote inherit that indent and the footnote must reset the indent to
                  ensure the block isn't indented at the bottom of the page.

                  Two commercial implementations that are available right now produce
                  different results because of the choices of "common sense" vs. "verbatim
                  interpretation of the specification".

                  >If the spec means that basic-link should propagate hot areas to all
                  >_contained_ areas, not just to _containing_ ones, then it should
                  >be worded as such,

                  Yet so many in the industry are expecting the entire contents of the basic
                  link to be hot (i.e. the contained areas) and not just the basic link (i.e.
                  the containing area).

                  Can someone on the XSL committee comment on whether the basic-link
                  controversy is perhaps an erratum that hasn't yet been published?

                  Thanks!

                  ................... Ken


                  --
                  Upcoming hands-on in-depth 3-days XSLT/XPath and/or 2-days XSL-FO:
                  - North America: Sep 30-Oct 4,2002
                  - Japan: Oct 7-Oct 11,2002

                  G. Ken Holman mailto:gkholman@...
                  Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
                  Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
                  ISBN 0-13-065196-6 Definitive XSLT and XPath
                  ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
                  ISBN 1-894049-07-1 Practical Formatting Using XSLFO
                  XSL/XML/DSSSL/SGML/OmniMark services, books (electronic, printed),
                  articles, training (instructor-live,Internet-live,web/CD,licensed)
                  Next public training: 2002-08-26,27,09-30,10-03,07,10,12-08
                • David Tolpin
                  ... Should footnotes anchored inside a basic-link be hot? David
                  Message 8 of 17 , Aug 23 8:05 PM
                  • 0 Attachment
                    > >If the spec means that basic-link should propagate hot areas to all
                    > >_contained_ areas, not just to _containing_ ones, then it should
                    > >be worded as such,
                    >
                    > Yet so many in the industry are expecting the entire contents of the basic
                    > link to be hot (i.e. the contained areas) and not just the basic link (i.e.
                    > the containing area).
                    >

                    Should footnotes anchored inside a basic-link be hot?

                    David
                  • G. Ken Holman
                    ... Why not? But I take your point, and it is a good one. Indeed one could make the argument for only normally flowed areas, but again only based on common
                    Message 9 of 17 , Aug 24 5:38 AM
                    • 0 Attachment
                      At 2002-08-24 08:05 +0500, David Tolpin wrote:
                      > > >If the spec means that basic-link should propagate hot areas to all
                      > > >_contained_ areas, not just to _containing_ ones, then it should
                      > > >be worded as such,
                      > >
                      > > Yet so many in the industry are expecting the entire contents of the basic
                      > > link to be hot (i.e. the contained areas) and not just the basic link
                      > (i.e.
                      > > the containing area).
                      > >
                      >
                      >Should footnotes anchored inside a basic-link be hot?

                      Why not? But I take your point, and it is a good one. Indeed one could
                      make the argument for only normally flowed areas, but again only based on
                      common sense and not on the reading of the specification.

                      I'm anxious to see what the errata will have to say (as yet empty):

                      http://www.w3.org/2001/10/REC-XSL-20011015-errata

                      Thanks, David,

                      .................... Ken


                      --
                      Upcoming hands-on in-depth 3-days XSLT/XPath and/or 2-days XSL-FO:
                      - North America: Sep 30-Oct 4,2002
                      - Japan: Oct 7-Oct 11,2002

                      G. Ken Holman mailto:gkholman@...
                      Crane Softwrights Ltd. http://www.CraneSoftwrights.com/f/
                      Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
                      ISBN 0-13-065196-6 Definitive XSLT and XPath
                      ISBN 1-894049-08-X Practical Transformation Using XSLT and XPath
                      ISBN 1-894049-07-1 Practical Formatting Using XSLFO
                      XSL/XML/DSSSL/SGML/OmniMark services, books (electronic, printed),
                      articles, training (instructor-live,Internet-live,web/CD,licensed)
                      Next public training: 2002-08-26,27,09-30,10-03,07,10,12-08
                    • David Tolpin
                      ... Should a marker be hot when the fo:marker is a descendant of a fo:basic-link, or fo:retrieve-marker, or both? David
                      Message 10 of 17 , Aug 24 5:49 AM
                      • 0 Attachment
                        > > > >be worded as such,
                        > > >
                        > > > Yet so many in the industry are expecting the entire contents of the basic
                        > > > link to be hot (i.e. the contained areas) and not just the basic link
                        > > (i.e.
                        > > > the containing area).
                        > > >
                        > >
                        > >Should footnotes anchored inside a basic-link be hot?
                        >
                        > Why not? But I take your point, and it is a good one. Indeed one could
                        > make the argument for only normally flowed areas, but again only based on
                        > common sense and not on the reading of the specification.
                        >
                        > I'm anxious to see what the errata will have to say (as yet empty):
                        >
                        > http://www.w3.org/2001/10/REC-XSL-20011015-errata
                        >

                        Should a marker be hot when the fo:marker is a descendant of a fo:basic-link,
                        or fo:retrieve-marker, or both?

                        David
                      Your message has been successfully submitted and would be delivered to recipients shortly.