This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Help project structure


> -----Original Message-----
> From: Maggie Strevell 
> I don't need  the depth you mention so I haven't taken it that far.
> I also have files for which I want in the help file, but I 
> don't want in my table of contents. 

> -----Original Message-----
> From: David Cramer 
> The xsl for chunking is pretty hairy. It always hurts my head when I
> look at it. If we can figure out exactly what we want, I'm 

Oh good, it's not just me. Thanks, I guess I'll forego the .hhc automation
for now and stick with the manual help TOC. Like I said, it's not a
show-stopper.

> What you (and I) really want is for the xsl to check to see if there's
> content in the chapter or section before the next section 
> begins. So the following two cases would be handled differently:
> 
> Case 1: The following sibling of title != section... so there is a
> separate chunk and toc entry for the section titled Foo.
> 
> Case 2: The following sibling of the title = section, so there is no
> separate chunk for the section titled Foo. There could be a toc entry,
> but it would take you to a chunk that contains the title for Foo, the
> title for A subsection about foo, and the rest of A subsection about
> foo..." 

Talk about making your head hurt! As a help author, I need more (and easier)
control of the TOC than this algorithm implies. 

At the risk of beating a dead horse, I can't help but think that in help,
generating the TOC from the physical order of elements in the XML document
is like the tail wagging the dog. It makes sense for static printed books,
but when I write help I want my TOC to offer a logical view (or views) of
things without necessarily rearranging the contents of my document.

I wish I could suggest a mechanism. Maybe the currently generated .hhc could
be a first pass - a flat list of the TOC objects. Maybe this could become an
intermediate file, processed against some filtering defined in another file,
that allows the author to independently control the ordering, maybe even
other collections. Don't we already use external data files with
localization? Enough - now my head is hurting!

Denis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]