Dave Pawson [mailto:[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote: > > Dave Pawson [mailto:[EMAIL PROTECTED] wrote: > > > >> My basic point is that the author should identify duplicates > >> (perhaps from viewing the presented format) and do > something about it. > > > > > > I disagree with this, because it forces the author to > presume a specific > > output format when creating the source. > > That provided by docbook XSLT? I didn't understand your question. I don't want to code XML to work only for HTML output, because I might generate both PDF and HTML output from the same source. > > I think the transforms should be smart enough to collapse identical > > entries in HTML topics. However, if there is only one instance of a > > particular index term in a topic, then I agree that it should go > > directly to the anchor point rather than the top of the page. > > Which is becoming almost a programming language for indexing? I don't see a problem with that, if it's the right thing to do. I've seen some pretty creative XSL code. > They can't be collapsed if they point to quite different > points in the document? Or at least it wouldn't make > sense to me to do that. I think we'll need to agree to disagree on this point. I can see where you're coming from if you typically have long, long sections that translate to HTML topics. But most topic-based HTML output has reasonably short topics, and these are manageable chunks to deal with as index results. IMO, when you have a topic with two identical index entries that is even 2 or 3 screens long, then essentially much of the topic relates to that entry. If your topics are typically much longer than that, I agree this behavior wouldn't work. Perhaps the behavior could be controlled by a parameter. ************************* Rob Cavicchio Senior Technical Writer EMC Captiva EMC Corporation 10145 Pacific Heights Boulevard, 6th Floor San Diego, CA 92121-4234 P: (858) 320-1208 F: (858) 320-1010 E: [EMAIL PROTECTED] The opinions expressed in this message are my own and should in no way be interpreted to reflect the opinions of EMC. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
