From: Erkki I Kolehmainen (firstname.lastname@example.org)
Date: Fri Jun 25 2010 - 16:25:13 CDT
Ken and others,
At the time I was the European project team leader for the standardization
of the euro, and as such I was strongly pushing for the addition of the euro
sign to Latin-1, which could not be done without adding a new part, which
then had to be done for the visibility. I fully agree with Ken (as he quite
well knows, I trust) that no new character encoding standardization should
have been done for quite a while on anything but the 10646/Unicode. As is,
the use of any of the 8859 parts can no longer be really be justified for
any purpose, and with 10646/Unicode the euro sign works extremely reliably.
Lähettäjä: email@example.com [mailto:firstname.lastname@example.org]
Puolesta Kenneth Whistler
Lähetetty: 25. kesäkuuta 2010 22:48
Aihe: Euro Sign in 8859-15 (was: Re: Indian Rupee Sign to be chosen today)
> On Fri, 25 Jun 2010, I wrote
> > Even in the year 2010, the euro sign (¤) doesn't work reliably.
> in both the Unicode list and in the newsgroup de.test.
> unicode.org shows a euro sign:
> groups.google.com shows a currency sign:
And as the snark seems to be spreading about this, let's step
into the Wayback Machine for a moment...
When 8859-15 was originally proposed in 1997 (see SC2/WG3 N388R, for
those of you with deep document archives), primarily to add the euro
sign to an 8-bit character set (but also to "fix" 8859-1 for
French and Finnish), the U.S. NB voted against the subdivision
of work, claiming in the strongest of terms that the proposal
was inherently flawed and simply would not work to solve the
problem(s) it was addressed at.
I'll quote at length from the U.S. NB comments in SC2 N2994,
dated 1997-11-21, "Summary of Voting on SC 2 N 2910, Proposal for
Project Subdivision of project JTC 1.02.20: a new part of ISO/IEC
8859 for Latin Zero covering the EURO Symbol and Full Support for
the French and Finnish Language":
The US disapproves a project subdivision for ISO/IEC 8859-15 for
the following reasons:
1) It is the US long stated position that additional parts of
8859 should not be created, except to capture existing 8-bit
practice (viz Part 11). Rather than addressing problems with
particular solutions, which are extremely costly to implement,
industry efforts should be focused on implementing
comprehensive solutions via the support of ISO/IEC 10646.
2) From document WG3 N 388 it is clear that the intent is to
replace ISO 8859-1, for the same user community. Because of
the prominent role that 8859-1 has gained as the default
character set in many internet protocols, introducing a near
equivalent standard will have disastrous effects. Due to their
large intersection part 1 and part 15 would appear to inter-operate
without proper adherence to announcing mechanisms. Were part 15
accepted and widely implemented, the result would be that no one
could be sure that ANY character from the non-intersecting part of
each set can be used reliably. In many ways, this situation is
reminiscent of the problems that plagued the 7-bit sets of ISO 646.
3) The adoption of ISO/IEC 10646 by the vendor community is
making rapid progress, therefore it cannot be argued that a
flawed solution must be accepted for lack of practical
It was already clear 13 years ago that 8859-15 wasn't going
to work. It shouldn't be too surprising that 13 years later
it still isn't working.
As Mark indicated, the answer here is not to expect distributed
systems to be able to reliably distinguish 8859-1 and 8859-15,
when neither labelling nor heuristics for distinguishing them
are reliable in the first place. The answer for reliable
representation of the euro sign is to use UTF-8. And that answer
was already obvious in 1997.
This archive was generated by hypermail 2.1.5 : Fri Jun 25 2010 - 16:28:12 CDT