On Fri, Feb 22, 2019 at 11:22:59AM +0100, Patrice Dumas wrote: > > So I think if we want such a file-local encoding, we should introduce > > a new command, @fileencoding, say. That would be backward-compatible.
Let's wait until somebody actually needs it and can't easily convert the files to UTF-8. I doubt that this would ever happen. > 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. @documentencoding primarily specifies the input encoding, as far as I understand. A user might conceivably override the output encoding, but they would never have reason to override the input encoding as specified by @documentencoding, provided that it was correct.
