Dear Bruno,
thanks a lot for your fixes! I've applied them almost verbatim.
> - "chinese-euc" is an alias for GB2312. I looked it up in the
> XEmacs sources.
Can you provide a complete list of encodings supported on XEmacs (the
latest version preferred)? I would like to mark them correctly in my
table for reference purposes.
> - EUC-JISX0213 and Shift_JISX0213 are supported by glibc and
> libiconv nowadays. You can add them to the table.
I suppose those encodings exist on XEmacs, right?
> - Do you know the distinction Emacs makes between "iso-2022-jp-3",
> "iso-2022-jp-3-compatible", and "iso-2022-jp-3-strict"?
No, but I assume it is related to the positions where ISO-2022 escape
sequences are in the data stream -- the `strict' one probably avoids
states crossing a newline character. Do you have details?
> - In BOM_table, I would not comment out the little-endian UTF-32
> BOM. It is the only way to prevent misinterpreting a file in
> little-endian UTF-32 as little-endian UTF-16. You have to trust
> that the input file will not have NUL characters.
Well, it's actually not necessary to make a difference: The `extract'
method of the groff's `string' class removes all null bytes before
passing the data to the function which tests for the coding tag --
note that `check_encoding_tag' is called before `iconv'.
Werner
_______________________________________________
Groff mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/groff
