[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
questions about (docbook) formatting
From: |
Patrice Dumas |
Subject: |
questions about (docbook) formatting |
Date: |
Fri, 29 Aug 2008 14:16:01 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello,
First questions that are not linked to docbook only but may have more
wider texinfo language implications:
* I think that index entries (like @cindex ..) should not open a
paragraph if there is no paragraph opened (but may happen in
paragraph). In the docbook output it can happen that <indexterm>
commands are alone in paragraphs, within @def* or @*table, it seems
to me that it is wrong.
* When some text appears before the first @item in @*table, @mutitable,
@itemize, @enumerate, it is not said in the texinfo manual how this
text will be interpreted.
In docbook it seems to me that it is considered as the title of the
construct, and no paragraph is opened. Should this be considered
a texinfo language feature?
* In @*table, it seems to me that the interpretation of constructs like
@item a
@cindex index
@itemx b
Text.
@item other item
is not obvious. The first interpretation could be that the @cindex is
in the entry beginning with address@hidden a' and ending in address@hidden
other item',
between @item and @itemx but not really part of the terms. However
in docbook the varlistentry is (term+ , listitem), so that one cannot
have an indexterm between the term. In that case it is still possible
to interpret the construct as
@item a
@cindex index
@item b
Text.
@item other item
address@hidden index' becoming a table definition grouped with address@hidden a'
while address@hidden b' would be grouped with `Text.'.
Although having both interpretations could be doable in the
implementation, I am not sure that it is wise.
Opinions?
A similar issue arises with
@deffn(x) aaa
@cindex index
@deffnx bbb
* This is a docbook only issue. In docbook elements mapped from @def*
(at least in <function>) the only allowed elements seemsto be <replaceable>
and <type>. And <replaceable> (haven't looked at type, but I guess it is
the same) doesn't seem to accept any style command. So I think that the
best would be to keep the detection of replaceable/type/delimiter as it is
now, output delimiters as is, and remove any command in <type> and
<replaceable>, to produce some text formatted in the same way than text
appearing in attributes (most commands removed, entities accepted, some
formatting possible, but without any <element>).
Does it seems right?
--
Pat
- questions about (docbook) formatting,
Patrice Dumas <=