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. 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
smime.p7s
Description: S/MIME cryptographic signature
