Re: Possible error in 7.22.7. indicate-destination

First, thanks for the quick reply.

Paul Grosso wrote on 21.05.2004 16:32:21:

> The source is the contents of the fo:basic-link, and your stylesheet
> can apply any property you want to that content--for example, 
> it is common.
> The indicate-destination allows the target of a basic-link to be, say,
> highlighted in some fashion.  The use case is as clear as highlighting
> the source, I guess.  Some people like to know what elements in their
> document are potential link targets.  (The fact that support for
> indicate-destination is so rare indicates to me that the use case is
> not a common one, but the use case isn't hard to understand.)

Yes, indeed not hard to understand. It just looked like an extremely
rare use case. After all, for internal destinations you could apply
the same logic as you did for the link source - just use any
fo formatting you like in the referenced element.

That's why I assumed the property was meant the other way around.
> I'm not entirely sure what you mean by "indicate to the PDF renderer 
> when to make links visible and when not" (I am not a PDF expert), but
> visibility is an XSL FO property.  If you want to make such visibility
> dynamic, consider using the fo:multi-switch FO.
> If there is something else you need to tell the PDF renderer, you might
> need to invent and use your own property.

Then let me elaborate:

Let's say you want to format an FO document as PDF with the
purpose of printing as well als supplying online reference. In
reference documents, you probably want to have as many links as
possible. Most people also want to see the links so they know
where they can klick. In contrast, when *printing* the document
you usually don't want the links marked up, because they are
of no use to you when printed and can really clutter your printout.

That is why in PDF you can have links that have a visualization
(e.g. border) only when viewed, but not when printed. For example,
you can have a 1 pixel border around your link source that does
not print. Of course, you can achieve a similar result when
applying different stylesheets, but then you have to supply two
different PDFs to your audience.

Sure, custom properties are always a solution, but I try to use
standard elements and properties wherever possible. HTML chaos
is not what we want in the XSL world, right? 8-)

In any case, thanks for the clarification. If the property was
intended this way, then of course its meaning cannot change and
I now know not to use it for that purpose.

If it helps, I am certainly willing to supply a proposal wording
for an additional property that does what I'd like to do. I'm
pretty sure other FO implementors producing PDF can also see
a use for it.


Arnd Beissner
Arnd Bei▀ner
Cappelino Informationstechnologie GmbH

Received on Friday, 21 May 2004 11:20:55 UTC