Niko Tyni <[EMAIL PROTECTED]> writes: > OK, it's your call of course. > > Both patches have the one important property: they can't break anything > when the utf8 option isn't used. I don't see any point in diverging, > so I think the attached patch (based on yours but cleansed of the > unrelated stopword changes) is the best choice for Lenny.
As mentioned in the debian-release response, it looks good to me. I've been thinking about how best to fix this in the long run, and I think that there are ways of handling this so that the caller doesn't have to be aware of the encoding of the output file handle but also without overwriting global state. I just haven't had a chance to implement it yet, but I think I can preserve the API presented by setting the encoding on the file handle in future versions. The basic idea will be to use PerlIO to probe the encoding layers on the output file handle. If PerlIO isn't available, or if PerlIO reveals no encoding layers, then Pod::Man and Pod::Text can just call encode before printing the output. If PerlIO is available with an encoding layer, but the encoding layer is UTF-8, we can continue without doing anything encoding (and this will catch the PERL_UNICODE case). If the encoding layer is something incompatible, I'll probably throw an error in the event that utf8 is set and otherwise trust it. Not sure when I'll get to implementing this, since I have a vacation coming up (and it's too late for lenny anyway), but definitely for squeeze we should be able to clean this up further. Thank you very much for all of your work on this. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
