Niko Tyni <nt...@debian.org> writes: > It's clearly still true, and I can't see any fix for it other than > adding =encoding utf8 lines in the POD files where necessary.
> However, I think all the documents that are rendered incorrectly with > --utf8 are already rendered incorrectly now, albeit in a different > way. See below. Yes, without the --utf8 option, pod2man assumes that it can only use 7-bit ASCII, and hence mangles non-ASCII characters pretty badly. This is required for completely portable *roff output, since high-bit characters can even cause segfaults on some really old, broken *roff implementations. But this is probably now too conservative. I think the default, if --utf8 is not given, should probably be to just encode output in whatever the default local locale is and assume that people will do something else if they have to generate *roff that works on old, broken systems. I'm not sure what to do if that locale is C, though. -- Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
