help-texinfo
[Top][All Lists]
Advanced

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

Re: [help-texinfo] Changing background color of the 'verbatim' environme


From: Patrice Dumas
Subject: Re: [help-texinfo] Changing background color of the 'verbatim' environment
Date: Thu, 29 Nov 2012 13:22:52 +0100
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Nov 29, 2012 at 04:17:55AM +0100, Thien-Thi Nguyen wrote:
> 
> Since this last exchange a couple months ago, i've tried to answer "in
> which format" by playing w/ code.  (I agree that makeinfo should be
> hands-off, for the most part, btw.)  If you get a chance, please see:

I had the opposite idea.  To me, the idea was that makeinfo would
generate both the XML that describe the nodes, and the IXIN file 
that describes the whole document.  All the code is already there, since
makeinfo basically has in memory all this information to be able to do
the HTML output.  If you want to have the code as lisp, sure it won't
be convenient, but doing it in makeinfo/texi2any should be very simple,
using the XML backend for the nodes, and the code used for HTML for the
indices as it is very similar.

> http://www.gnuvola.org/software/ixin/
> 
> I think the priority is to define the "container shape", which is what
> IXIN 1.0 aims to do; precise design / interpretation of the (S)XML-ish
> contents can be done later.  What do you think?

A agree, although I think that using the texinfo XML would be the correct 
thing to do: if it is not suitable, that would certainly show that it
has to be modified.


Some remarks:

* sectionning tree.  I think that, in addition to the node tree, the 
  sectionning tree (@part, @chapter, @section, @unnumbered...) should be
  present and index the corresponding nodes too.

* the meta part is not completly clear to me.  Is the idea to have a 
  container for information set for the whole document:

          'documentdescription',
        'evenfootingmarks', 'evenheadingmarks',
        'everyfootingmarks', 'everyheadingmarks',
        'fonttextsize', 'footnotestyle', 'novalidate',
        'oddfootingmarks','oddheadingmarks',
        'pagesizes', 'setchapternewpage',
        'setcontentsaftertitlepage',
        'setfilename',
        'setshortcontentsaftertitlepage',

  or something else?

* if you want 'random' access to nodes, you need to also give some
  information on the document state at the beginning of the node.
  Roughly, this corresponds to

       'allowcodebreaks', 'clickstyle', 'codequotebacktick',
        'codequoteundirected', 'deftypefnnewline',
        'documentencoding', 'documentlanguage', 'exampleindent',
        'firstparagraphindent', 'frenchspacing', 'headings',
        'kbdinputstyle', 'paragraphindent',
        'urefbreakstyle', 'xrefautomaticsectiontitle',

  And the processor should be able to process an information of a change
  in those.  Some may not be needed, in fact if the information is
  already in the XML (for instance, I think clickstyle is also in an
  attribute of @click or something like that).

* index of indices entries.  At least the node containing the indices
  entries (@cindex...) should be indexed somewhere, to be able to format a
  printindex.  I that that it would be even better to have an XML
  representation of the index entry text.  

A last remark, using a base64-encoded gzipped nodes representation seems
weird to me, why not simply an xml file per node with a file name
constructed similarly as for html, with additional care for avoiding to
have different nodes in the same file?  Is the point having everything
in only one file?

For the index entries, maybe the base64 stuff would be useful for rapid 
direct access.

-- 
Pat



reply via email to

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