Frank da Cruz wrote:
Doug Ewell wrote:
That last paragraph echoes what Frank said about "reversing the layers,"
performing the UTF-8 conversion first and then looking for escape
sequences. True UTF-8 support, in terminal emulators and in other
software as well, really should depend
Erik van der Poel wrote:
Frank da Cruz wrote:
The irony is, when using ISO 2022 character-set designation and invocation,
you have to handle the escape sequences first to know if you're in UTF-8.
Therefore, this pushes the burden onto the end-user to preconfigure their
emulator for UTF-8
Frank da Cruz wrote:
Yes, but I was thinking more about the ISO 2022 invocation features than the
designation ones: LS2, LS3, LS1R, LS2R, LS3R, SS2, and SS3 are C1 controls.
The situation *could* arise where these would be used prior to announcing
(or switching to) UTF-8. In this case,
Frank da Cruz [EMAIL PROTECTED] wrote:
. If you send a code in the 0x80-8x9f range to such a terminal or
emulator, it properly treats it as a control code. If it was
intended as a graphic character ("smart quote" or somesuch) the
result is a fractured screen, sometimes even a
4 matches
Mail list logo
