bug-texinfo
[Top][All Lists]
Advanced

[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




reply via email to

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