From d959146d4376cd67d889b56538b5490b178f1fc3 Mon Sep 17 00:00:00 2001 From: simon Date: Tue, 13 Sep 2005 22:09:02 +0000 Subject: [PATCH] I've apparently had this todo-list comment sitting on stormhawk for nearly a year and not checked it in. git-svn-id: svn://svn.tartarus.org/sgt/charset@6309 cda61777-01e9-0310-a592-d414129be87e --- iso2022s.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/iso2022s.c b/iso2022s.c index 3b01529..000c57e 100644 --- a/iso2022s.c +++ b/iso2022s.c @@ -713,6 +713,33 @@ static const struct iso2022_escape ctext_escapes[] = { SEQ("\033-H", 1, CTEXT_ISO8859_8), SEQ("\033-L", 1, CTEXT_ISO8859_5), SEQ("\033-M", 1, CTEXT_ISO8859_9), + + /* + * Cross-testing against Xutf8TextListToTextProperty() turns up + * some additional character sets and ISO 2022 features + * supported by that and not by us: + * + * - Single-byte right-hand-half character sets `ESC - f', + * `ESC - T' and `ESC - Y'. + * + * - A really horrifying mechanism used to escape completely + * from the ISO 2022 framework: ESC % / + * . Xutf8* uses this to encode + * "iso8859-14", "iso8859-15" and "big5-0". + * * This mechanism is particularly nasty because we can't + * efficiently encode it on the fly! It requires that the + * length of the text encoded in the foreign charset is + * given _before_ the text in question, so if we're + * receiving one character at a time we simply can't look + * ahead and so we would have to encode each individual + * character in a separate one of these sequences. + * + * - ESC % G and ESC % @ to shift to and from UTF-8 mode, as a + * last resort for anything we still don't support. + * * Interestingly, ctext.ps actually _disallows_ this: it + * says that the above extension mechanism is the only + * one permitted. Ho hum. + */ }; static const struct iso2022 ctext = { ctext_escapes, lenof(ctext_escapes), -- 2.11.0