Re: Assume CP1252

On Jan 12, 2015, at 11:18 AM, Karl Williamson <[email protected]> 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. 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.

>> 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