Bug#492037: Bug#500210: perldoc perlrun spits out junk in synopsis

[Dominic Hargreaves]

Tags: -1 - patch

On Mon, May 23, 2011 at 04:05:11PM -0700, Russ Allbery wrote:
> Niko Tyni <ntyni at 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.

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)