Thanks for your reply, Werner: > What about doing it the naive way? > > File `lcuc' in UTF-8 encoding: > [...] > Provided you have proper PS fonts, this works with > -Tps also. > > Am I missing something?
Your example works perfectly with -Tutf8 if the source file is in UTF-8 and the -K preprocessor is used, and was the first thing that I tried. But it does not work either for -Tlatin1, or for -Tutf8 with the source in KOI8-R, which is converted to Unicode entities using your koi8-r.tmac (included by mru_utf8): #input: a text file in KOI8-R #ouput: a text file in KOI8-R #(ru.tmac here defines no character translations, # only hyphenation codes and patterns) groff -Tlatin1 -mm -mru test.mm > test.txt #input: a text file in KOI8-R #ouput: a text file in UTF-8 #(ru_utf8.tmac defines character translations of 8-bit input chars onto # corresponding unicode entities, according to the KOI8-R encoding) groff -Tutf8 -mru_utf8 -mm test.mm > test.txt #input: a text file in KOI8-R #ouput: a PostScript file groff -Tps -mru_utf8 -mm test.mm > test.ps Your suggestion doesn't work with either of these (otherwise functional) scenarios. I understand why it is not suitable for the second and third exam- ples -- that's probably because .tr "doesn't handle translations of translations", which can be mended by a bigger device-dependent .tr request like this (this e-mail is in KOI8-R): .tr а\[u0410] .tr б\[u0411] .tr в\[u0412] ... But I couldn't come up with anything similar for -Tlatin1. This doesn't work: .tr а\[char225] .tr б\[char226] .tr в\[char247] ... Of course, I could use iconv to preconvert the input file to UTF-8 and, when needed, convert the result- ing file back to KOI8-R, thereby using groff the way you suggested (with -K), but I think it's cumber- some... Anton
