porters,
I have decided to release Encode 1.79 so soon after 1.78 with two
reasons.
Whole:
http://www.dan.co.jp/~dankogai/Encode-1.79.tar.gz
and CPAN
=head1 reasons
=over
=item 1
The latest patch to Encode.(pm|xs) by Nick In-XS to relocate
Encode::utf8 from .pm to .xs has introduced a minor bug that was
revealed in t/mime-header.t. It was due to the fact that
Encode::utf8->decode() attempts to decode even when the argument is
already flagged as utf8 string. Encode 1.78 fixed the problem by
mending lib/Encode/MIME/Header.pm but Nick In-XS has sent me a patch to
Encode.xs.
=item 2
M$ version of the mapping in cp949 (Korean) and cp950 (Trad. Chinese)
was obsolete, resulting U+20AC (EURO SIGN) and U+00AE (REGISTERED
SIGN) missing. This time Moriyama-san has tested them against
conversions via Win32 API and verified that they all matches now (at
leased those marked as round-trippable).
=back
=head2 grumbles
Frankly, I am f.*ing tired of hearing about any M$-related char map
issues. This is to close the cp9?? cases altogether. From now on I
will happily ignore any claims saying 'cp??? seems to be wrong' unless
M$ fixes their web pages (
http://www.microsoft.com/typography/unicode/cscp.htm -- it's gone!) and
THE ATTITUDE (no news on the shutdown of the page above was released to
the community). I have just had enough, m'kay?
=head1 Changes
$Revision: 1.79 $ $Date: 2002/10/21 06:05:37 $
! Encode.xs
Further patches from NI-XS. Encode::utf8->decode() now checks the
value of utf8 flag of the argument. As a result, the fix to
lib/Encode/MIME/Header.pm is no longer neccessary but since it did
no harm (even speedwise) I'll leave it unreverted.
! ucm/cp949.ucm ucm/cp950.ucm
U+20AC EURO SIGN
U+00AE REGISTERED SIGN
were missing as a result of 1.78. Discovered by Moriyama-san.
Moriyama-san has also developed a test script that compares
(en|de)coded results to the corresponding Win32 API result and
all cp9?? maps are now verified.
Message-Id: <[EMAIL PROTECTED]>
=head1 AUTHOR
Dan the Encode Maintainer
