On Sat, Aug 30, 2008 at 07:11:42PM -0500, Karl Berry wrote: > > * In @*table, it seems to me that the interpretation of constructs like > @item a > @cindex index > @itemx b > > Text. > > In general, all we can say is that there are two items and one index > entry. We cannot say if the index entry "belongs" to either of them. > > The one thing that we know for sure is that "Text" belongs to both > items.
Ok. This rules out one of the interpretations. > Does the Docbook DTD have a concept of this kind of list? Or > does > @item a > @itemx > Text. > have to turn into whatever docbook calls the HTML > > <dt>a</dt> > <dd></dd> > > <dt>b</dt> > <dd>Text.</dd> No, docbook has a concept of list, and the correct output for your example is <varlistentry> <term> a </term> <term> b </term> <listitem> Text. </listitem> </varlistentry> which is a bit different from the html since here there is an explicit grouping of the 2 terms in a <varlistentry> in docbook, while in html it is not enforced. > However in docbook the varlistentry is (term+ , listitem), > > You mean, in the actual Docbook definition or just in what makeinfo does? It is the Docbook definition. It means that something like <varlistentry> <term>a</term> <indexterm role="cp"><primary>index</primary></indexterm> <term>b</term> <listitem>Text.</listitem> </varlistentry> is invalid, because an <indexterm> cannot appear in a <varlistentry> (unless I am missing something). (I don't remember exactly what makeinfo does, but it is something like the snippet above. It is the most logical formatting indeed, from a texinfo perspective). > I'm not sure what our options are. Maybe the most logical would be to produce <varlistentry> <term>a</term> <term><indexterm role="cp"><primary>index</primary></indexterm>b</term> <listitem>Text.</listitem> </varlistentry> This would avoid having to have to look forward when processing @item a. And if there is no @itemx, then the index entry would be in the listitem. -- Pat
