Tags: -1 - patch On Mon, May 23, 2011 at 04:05:11PM -0700, Russ Allbery wrote: > Niko Tyni <[email protected]> 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.
Niko's patch to use pod2man --utf8 was applied (and then the code was rewritten...). As we have seen during the perl 5.18 rebuild testing, missing =encoding is now a fatal error. I think these points mean that this bug is essentially fixed with Debian (experimental) and should be closed. I will aim to verify this using the test case provided by the original submitter before closing this bug (I don't have access to a suitable test system at the moment, but I wanted to record this on the bug report whilst at least some of the details were in my head). -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
