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

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

Expand Messages
  • David Cramer
    Ah. Is that what: NOTE: An fo:basic-link can be enclosed in an fo:block to create a display area
    Message 1 of 17 , Aug 9, 2002
    • 0 Attachment
      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? "display area" sounds like a technical term, but that
      is the only occurrence of it I find.

      I'm using xep btw.

      Thanks,
      David

      > -----Original Message-----
      > From: G. Ken Holman [mailto:gkholman@...]
      > Sent: Friday, August 09, 2002 3:12 PM
      > To: XSL-FO@yahoogroups.com
      > Subject: Re: [XSL-FO] line-height of a basic-link around an
      > external-graphic
      >
      >
      > 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.
      >
      > .................. 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
    • 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 2 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 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
          ... 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.