On Tue, Feb 19, 2019 at 06:22:20PM +0200, Eli Zaretskii wrote: > > > > Looking at the perl parser, it seems that the encoding is reset for all > > the input files upon reading @documentencoding, so a @documentencoding > > in an include file resets the main file documentencoding. I would say > > that this is incorrect. > > Whether a mistake or not, this command exists in Texinfo for too long > to change it now in backward-incompatible ways. It always produced a > global setting which was in effect for the whole document. > > The main use case of @documentencoding is exactly to specify a single > encoding for the entire document. The use case you propose sounds > like a much more marginal one. In fact, I cannot even envision when > would that be useful -- to produce an HTML document where each section > is in a different language, perhaps?
No, but to handle includes of input files that are not in the same encoding. > So I think if we want such a file-local encoding, we should introduce > a new command, @fileencoding, say. That would be backward-compatible. I think that it could be a good idea. Currently, @documentencoding does two things, it specifies the input encoding, but also the output encoding. I think that it is not a good idea to do both, as the output encoding could be different from the input encoding and different for different output formats. For instance, in XML and Docbook output, UTF-8 is always used for the output. But even in that case, it could be relevant to change in a not backward compatible way the meaning of @documentencoding, such that it only specifies the output encoding. -- Pat
