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

line-height of a basic-link around an external-graphic

Expand Messages
  • cramerdw
    Given this fo:
    Message 1 of 17 , Aug 9 12:57 PM
      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. I could increase the line-height of the basic-link, but how can the xsl know what value to put there if the width and height aren't specified? Is there another way in fo to do the equivalent of <a href="foo.html"><img src="foo.gif"/></a> where the entire image is hot?

      Thanks,
      David
    • G. Ken Holman
      ... This sounds like a bug in your implementation ... Antenna House makes the entire image hot. .................. Ken -- Upcoming hands-on in-depth 3-days
      Message 2 of 17 , Aug 9 1:12 PM
        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
      • David Cramer
        Ah. Is that what: NOTE: An fo:basic-link can be enclosed in an fo:block to create a display area
        Message 3 of 17 , Aug 9 2:03 PM
          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 4 of 17 , Aug 9 2:23 PM
            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 5 of 17 , Aug 11 3:52 AM
              >
              > 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 6 of 17 , Aug 11 3:52 AM
                >
                > 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 7 of 17 , Aug 11 3:53 AM
                  >
                  > 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 8 of 17 , Aug 11 8:21 AM
                    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 9 of 17 , Aug 11 4:08 PM
                      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 10 of 17 , Aug 12 6:09 AM
                        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 11 of 17 , Aug 12 7:01 AM
                          >>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 12 of 17 , Aug 12 2:45 PM
                            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 13 of 17 , Aug 12 3:22 PM
                              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 14 of 17 , Aug 23 12:58 PM
                                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 15 of 17 , Aug 23 8:05 PM
                                  > >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 16 of 17 , Aug 24 5:38 AM
                                    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 17 of 17 , Aug 24 5:49 AM
                                      > > > >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.