At 23:11 13/05/2004, Karsten Wade wrote:
> I've seen the pi's being used, but have you tried
> > <qandaset defaultlabel="qanda"
> >+ <?dbhtml toc="1"?>
> > <qandaentry>
> instead? That normally causes the toc insertion.
> Its not valid (the toc element) where you have the pi, must it be there?
I'm still not understanding completely. The processing instructions
(PIs) are a valid way of tackling this, yes?
Ambivalent about that, since there are no pi's in the dtd :-)
Or is the problem that
this one is only really good for HTML output?
I'm saying docbook provides a way of automatically generating
a toc itself?
If you use a toc element, try validating it
with the toc element in place, or read about it in tdg?
I also didn't have success with the <toc />. In my
<article>, the only
place I can validly insert a <toc></toc> block is inside of the
These elements contain toc:
Doing so doesn't make it appear in the rendered HTML, probably
because of the stylesheet again, although I can't see why. 'sect1 nop'
in main-html.xsl disables ToCs for the sections, and a ToC is generated
and enabled via 'article toc'.
Read up on where/when you want tocs in the doco for the stylesheets.
I also discovered that the mere inclusion of 'qandadiv toc'
<xsl:param name="generate.toc"> section of fedora-docs/xsl/main-html.xsl
is enough to generate the ToC that appear after the title of each
Yep, that's your 'control' aspect of where and when you want a toc.
The only way I have successfully created the entire 'table
of questions' for the <qandaset> is with the PI <?dbhtml
/me scratches his head
I'm happy with my hack for the moment, but I'm not happy with not fully
understanding _why_ it works as it does. Back to the books ...
If you want one, and its not supported,
put in the request at sourceforge,
or mail it to the docbook-apps list?