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

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

Expand Messages
  • G. Ken Holman
    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
    • Show all 17 messages in this topic