On 01/12/2015 12:37 PM, David E. Wheeler wrote:
On Jan 12, 2015, at 11:18 AM, Karl Williamson <pub...@khwilliamson.com> wrote:
To be clear, I think that assuming 1252 when there is no =encoding
line is a good idea. But I'm leery of overriding an actual =encoding
line.
Agreed.
I’m okay with this.
I could possibly be persuaded, if someone want to make it, by the argument that 'latin1'
is kind of colloquial, and someone using it may very well not be familiar with the
possibility that they really mean cp1252. But, if so, there needs to be a way for
someone to say "I really mean it" and not be overridden by us. Perhaps
that could be =encoding "ISO-8859-1".
If we *were* to assume CP1252 for Latin-1, I would want it to be consistent
with the precedent set by the W3C.
That sounds reasonable.
Sean supplied this link:
http://www.w3.org/TR/encoding/#names-and-labels
Here’s the list of labels that they translate to Windows-1252:
"ansi_x3.4-1968"
"ascii"
"cp1252"
"cp819"
"csisolatin1"
"ibm819"
"iso-8859-1"
"iso-ir-100"
"iso8859-1"
"iso88591"
"iso_8859-1"
"iso_8859-1:1987"
"l1"
"latin1"
"us-ascii"
"windows-1252"
"x-cp1252"
In their interpretation, no label ever resolves to iso-8859-1. Pretty
interesting.
I ran across this link, but didn't see what action was taken on it:
http://www.w3.org/TR/newline
Q: What if there is more than one =encoding line? Does it switch
encoding part way thru a POD?
Error while formatting with Pod::Perldoc::ToMan:
Nested processed encoding. at /usr/share/perl/5.18/Pod/Simple/BlackBox.pm line
380.
I recently changed this error, because that was a pretty useless message. The new message
is "Cannot have multiple =encoding directives". Also, it is no longer fatal,
but is passed to scream(), which means it would be a failure for Test::Pod, but won’t
break tools that generate docs.
http://github.com/theory/pod-simple/commit/cb884b5
Best,
David
