> Date: Mon, 21 Dec 2015 19:51:56 +0000 > From: Gavin Smith <[email protected]> > Cc: Texinfo <[email protected]> > > > http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00111.html > > http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00113.html > > > > So I suggest we fix this in Info by adding a call to 'iconv' when the > > conversion returns with success. > > Sounds good, I'm not opposed to such a change. Will you write the > change?
OK. > Out of curiosity, what is the state shift character in CP1255? No, cp1255 doesn't have it, if I understand what you are asking. The problem is that some cp1255 characters are combining characters, so libiconv composes them with the preceding character into a single codepoint of the corresponding precomposed character, and only after that produces the UTF-8 sequence of that codepoint. So it needs to be told there will be no next character for it to output the last UTF-8 sequence. > In theory there's a problem with the interpretation of shift > characters, especially locking shifts in the Info format, because you > have to ask what the shift state should be for things like the "File:" > keyword. Probably not a real problem though - Info files in encodings > like ISO-2022-JP probably don't exist. We also convert when writing to the screen, if the locale's codeset requires that.
