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

[Patrice Dumas]

On Mon, Dec 03, 2012 at 06:59:15PM +0100, Thien-Thi Nguyen wrote:
> 
>    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.
> 
> Hmmm, if i understand correctly, you want to maintain VARS and SETTINGS
> in META, but modify INDEX entries to go from:
> 
>  (NAME LENGTH NEXT PREV UP)
> 
> to:
> 
>  (NAME LENGTH NEXT PREV UP [TWEAKS...])
> 
> where each TWEAK could override some element in VARS or SETTINGS.  In
> this case, there need not be any TWEAKs list at file top-level.  Does
> that sound right?  I think that would work, too.

Exactly.

>    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.
> 
> Unfortunately, plain text is easier to corrupt undetectably.  Too,

I still don't really get it.  Isn't Base64 encoded with offsets also
easy to corrupt?

> piping plain text around requires everyone to take pains about encoding
> issues on the outside of their program as well as on the inside (which
> is hard enough, look at all the kludges/bugfixes succumbed by a2ixin!).

This is certainly not an issue in reality: we can say that we only use
utf8, it is already what is used for Texinfo XML, a customization 
variable has to be used in order to avoid outputting utf8.

> Actually, a2ixin is not a good example -- its role is to mimic some
> future makeinfo, which we KNOW will DTRT :-D, rather than a renderer.

Indeed.

> Compression is good, generally, anyway.  On the other hand, base64
> indeed is superfluous.  I think i added that mostly for aesthetics.
> (But then again, it does help keep text encoding issues "internal".)

Human readable format plain text format is a huge gain in my opinion.
Easier to debug, to do textual substitutions, access is more rapid.
You can always compress the whole file, the gain should be even better
than compressing parts, and it leaves the choice to compress or not and
the compressor choice to the "user" of the format, not to the designer 
of the format.

-- 
Pat