> No, it looks like you're right. `info groff' says
>
> -- Request: .hcode c1 code1 [c2 code2 ...]
>
> Set the hyphenation code of character C1 to CODE1, that of C2 to
> CODE2, etc. A hyphenation code must be a single input character
> (not a special character) other than a digit or a space.
^^^^^^^^^^^^^^^^^^^^^^^^^
This explains why preconv doesn't work.
> Werner, is it a preconv bug that it doesn't produce ISO-8859-1
> (latin1) output where possible, e.g. รค rather than \[u00E4], given
> that's groff's default input encoding? It stops it being used for
> .hcode.
No, it's not a bug in preconv, it's a bug in troff: `.hcode' and `.hw'
are limited to raw 8bit characters. Instead, they should accept any
characters entities like `\[u00AD]'. Similarly, `.hpfcode' should be
modified to allow entities, too.
Please file an issue so that it is not forgotten.
Werner
PS: A clean solution currently is to put `.hw' lines into a separate
file that uses the proper 8bit encoding, and that file gets then
included with `.so'. Since `preconv' gets called before `.soelim'
in groff's pipeline, different encodings won't clash.
