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

RE: [XSL-FO] line-height of a basic-link around an external-graphic

Expand Messages
  • G. Ken Holman
    ... Nope. ... I would interpret that phrase as block-level area in contrast to an inline-level area ... a display area breaks the block-progression
    Message 1 of 17 , Aug 9, 2002
    • 0 Attachment
      At 2002-08-09 16:03 -0500, David Cramer wrote:
      >Ah. Is that what: "NOTE: An fo:basic-link can be enclosed in an fo:block
      >to create a display area"
      ><http://www.zvon.org/xxl/xslfoReference/Standard/slice6.html#fo_basic-li
      >nk> is getting at?

      Nope.

      >"display area" sounds like a technical term, but that
      >is the only occurrence of it I find.

      I would interpret that phrase as "block-level area" in contrast to an
      "inline-level area" ... a display area breaks the block-progression
      direction. Such terminology was used in DSSSL.

      So, the use of the phrase "to create a display area" causes the sentence to
      mean to me "the basic-link to break can be enclosed in an block to cause
      the construct to break to a new line". It doesn't have any influence on
      that part of the inline that is hot.

      I don't see any reason why the entire inline construct isn't hot, even if
      it is a tall graphic, and I'm seeing what I'm expecting when I use Antenna
      House.

      ............. 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-05,26,27,09-30,10-03,07,10
    • 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 2 of 17 , Aug 11, 2002
      • 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
      • 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 3 of 17 , Aug 11, 2002
        • 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
        • David Tolpin
          ... What is entire inline construct ? David Tolpin
          Message 4 of 17 , Aug 11, 2002
          • 0 Attachment
            >
            > I don't see any reason why the entire inline construct isn't hot, even if
            > it is a tall graphic, and I'm seeing what I'm expecting when I use Antenna
            > House.

            What is "entire inline construct"?

            David Tolpin
          • G. Ken Holman
            ... Thank you for the clarification ... but I am confused. ... Okay ... section 4.6 talks about the content rectangle in terms of the text dimension ... but I
            Message 5 of 17 , Aug 11, 2002
            • 0 Attachment
              At 2002-08-11 15:52 +0500, David Tolpin wrote:
              >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.

              Thank you for the clarification ... but I am confused.

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

              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.

              Also, 6.9.2 states "The object allows for traversal to the destination
              resource, typically by clicking on any of the containing areas", and the
              graphic does impact the area tree enough to ensure the line-stacking
              strategy of "maximum-line-rectangle" (default) accommodates the height of
              the graphic.

              I've looked for a description of "containing area" and cannot find one
              right away ... but if the area tree needs to accommodate the height of the
              large allocation rectangle (which I am assuming contains all of the graphic
              ... 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.

              Sorry for being dense about this, but I'm anxious to understand it correctly.

              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-05,26,27,09-30,10-03,07,10
            • 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 6 of 17 , Aug 11, 2002
              • 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 7 of 17 , Aug 12, 2002
                • 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 8 of 17 , Aug 12, 2002
                  • 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 9 of 17 , Aug 12, 2002
                    • 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 10 of 17 , Aug 12, 2002
                      • 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 11 of 17 , Aug 23, 2002
                        • 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 12 of 17 , Aug 23, 2002
                          • 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 13 of 17 , Aug 24, 2002
                            • 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 14 of 17 , Aug 24, 2002
                              • 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.