[Top][All Lists]

[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: Sat, 1 Dec 2012 09:27:20 +0100
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Nov 29, 2012 at 01:22:52PM +0100, Patrice Dumas wrote:
> * 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).

Afer ore thinking, and answering to myself, I think that the most
efficient would certainly be to have the value at the end of the
preamble for those commands in the META section, because, in most 
cases this is not changed in the document, and add in the index the 
state at the beginning of the node only if it differs from the 
value at the end of the preamble.

> 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?

After thinking a bit about it, indeed having everything in one file 
would be practical.  But I can't see what a base64-encoding and gzipped
representation adds.  A plain SXML text representation should certainly 
be better, with beginning and end of node indexes.  For figures, 
base64-encoded gzipped would make sense, though.


reply via email to

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