On Sun, Dec 25, 2022 at 10:03:51PM +0000, Gavin Smith wrote: > On Sun, Dec 25, 2022 at 10:45:04PM +0100, Patrice Dumas wrote: > > Hello, > > > > If I recall well, there was some previous discussions, I believe Gavin > > proposed something similar. > > > > As it is now --enable-encoding (ENABLE_ENCODING customization option) > > means something very different for Info/Plaintext and HTML/XML based > > formats. For Info/Plaintext is means using actual characters and not > > ASCII transliterations as far as poosible. For HTML/XML > > --enable-encoding means using characters instead of entities. It means > > something very different, in HTML/XML encodings support is enabled in > > any case (though not necessarily fully when encoding is US-ASCII), but > > the option is really about entities or not. > > I think this is a good idea. You might be referring to this mail I > sent: > > https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00065.html > From: Gavin Smith > Subject: Re: with HTML output, @minus{} is converted to a hyphen instead of a > real minus character > Date: Thu, 13 Oct 2022 19:30:07 +0100
Exactly. > > I would propose I sthat ENABLE_ENCODING only says something on supporting > > encodings or not, and that it has not much effect except for Info and > > Plaintext. I propose to use a customization variable for HTML/XML, > > for example named OUTPUT_CHARACTERS. > > Would the use of ENABLE_ENCODING simply be renamed to something else > in the code for HTML/XML? I think so, but I need to check, as ENABLE_ENCODING is used more generally for conversion to Text, which is common to more than one format. As a side note, to workaround that ENABLE_ENCODING is in general not set for HTML/XML, but we want to convert to Text as if it was set, there is a trick to do as if ENABLE_ENCODING was set even if it is not, by setting the second argument of Texinfo::Convert::Text::copy_options_for_convert_text to 1. Having a separate variable would allow to avoid needing that trick. So it may not be only renaming to something else, but the code could be simplified too. > If that's the case, then we could easily > change the name of the variable later if we think of a better name. Ok. -- Pat
