bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: questions about (docbook) formatting


From: Patrice Dumas
Subject: Re: questions about (docbook) formatting
Date: Mon, 1 Sep 2008 15:38:14 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]