On Mon, 2012-04-30 at 14:24 +0200, Johan Vromans wrote: > Grant McLean <gr...@mclean.net.nz> writes: > > > OK, so I went ahead and implemented both the warning and the heuristic > > to guess Latin-1 vs UTF-8 (only when no encoding was specified). The > > resulting patch is here: > > > > https://github.com/theory/pod-simple/pull/26 > > This patch enforces authors to add an "=encoding UTF-8" line to > specify that the doc is, indeed, UTF-8 encoded.
Not exactly. It generates a warning during the parsing process which will be visible in the output of any formatter that has error output enabled. It's not a fatal error so it doesn't exactly "enforce" anything. The aim is to help people comply with the spec for POD as it is currently written. And that spec says that if there are non-ASCII characters there must be an =encoding declaration. > Wouldn't it be far better to consider all POD documents to be Utf-8 > encoded Unicode and fall back to Latin1 if invalid UTF-8 sequences are > detected? You won't get any argument from me that UTF-8 would be a better default, but that's not how the spec is currently written. If your Perl source code includes UTF-8 characters, you must say: use utf8; If your POD includes UTF-8 characters, you must say: =encoding utf8 > In other words, do not enforce the author to add "=encoding > UTF-8" since that's the default? And only add "=encoding ISO8859-1" for > Latin1 encoded documents? The patch does also implement the heuristic recommended in the perlpodspec which has the effect of allowing either Latin-1 or UTF-8 to work (the default is ASCII) in spite of the missing declaration. This will be a win for sites like metacpan.org which currently don't display UTF-8 correctly from POD that lacks an =encoding declaration. Any formatter that has error display disabled will see better rendering of UTF-8 with this patch. Additionally, if errors are displayed, the non-compliance with perlpodspec will be reported. Regards Grant
