A 09:34 98-04-17 -0700, Tex Texin a écrit :
>Keld,
>There are a lot of "ought to's" in here. Why not wait until the demand is
>there? There is a substantial cost for companies to implement and test
>these changes, and to retain the integrity of existing data, and to make
>changes that may someday be useful or "convenient", does not seem
>justified.
>tex
[Alain] :
My idea is that for email, for example, it is important that MIME be
considered more seriously at once. This will minimize the necessity of
changing legacy data.
For example, Windows assigned a codepoint to the EURO SIGN in code page
1252. This does not need to change on the originator's machine. However, if
EBCDIC assigned a codepoint to the EURO SIGN, it is good that the exchange
between the two be done using Latin 9 as the hinge in the simple and
straightforward 8-bit-character-set-technology world.
In the same way the OE ligatures are already coded both on Windows and on
the Mac. It is desirable that they exchange data using MIME tagging and
Latin 9 coding, since we will now have an international standard for this
kind of exchange, until full-blown Unicode data requirements are justified
for really worldwide exchanges, in which case MIME tagging should be used
too in harmony. One does not contradict the other. Internally Unicode can
also be used, it is prudent *when feasible*.
Beyond Latin 1/9 in 8-bit world, I believe the requirement is as real as
for Western Europe/Canada. Implementers should of course wait for standards
instead of inventing new wheels in their own corner, but should also be
aware that these standards are inevitably to come, beyond private
registrations unless overnight eveybody goes to Unicode, in an ideal world
which does not exist (we just have to admit it and life becomes simpler;
why yet just another religious war?)
Alain LaBonté
Québec
______________________________________________
>On Apr 17, 8:20am, Keld J|rn Simonsen wrote:
>> Subject: Re: Euro in 8859 character sets
>> Jonathan Rosenne writes:
>>
>> > I understand why the Euro sign is wanted in Latin-1, Latin-0 and
>Greek, but
>> > I am not certain it is needed in other parts, such as Cyrillic,
>Arabic and
>> > Hebrew.
>> >
>> > I have no objection to vendors adding the sign to their private
>codes. The
>> > question is should it be added to the standards?
>>
>> For the Cyrlillic 8859 part, there are candidates to membership of EU,
>> and thus the Euro would become their national currency in due time.
>> It would be very convenient to those countries (which at least include
>> Bulgaria) if their national currency sign is present in the ISO
>> 8-bit standard that covers them.
>>
>> For the others I think it is not necessary, but I would think that
>> given the amount of trade with the EU from countries with Hebrew
>> or Arabic as their language - I expect the EU to be one of the biggest
>> trade partners there - the Euro sign should be of as much use to them
>as
>> the dollar sign is today.
>>
>> Keld
>>
>>-- End of excerpt from Keld J|rn Simonsen
>
>
>
>--
>--------------------------------------------------------------------
>Tex Texin Manager International Products
>
>Progress Software Corp. Voice: +1-781-280-4271
>14 Oak Park Fax: +1-781-280-4949
>Bedford, MA 01730 USA texin@bedford.progress.com
>
>http://www.progress.com http://apptivity.progress.com
>--------------------------------------------------------------------
>June 1-4, 1998 Americas Users Conference Dallas, Texas U.S.A.
>Aug. 17-19, 1998 Asia/Pacific Users Conference Melbourne, Australia
>Sept. 28-30, 1998 European Users Conference London, England
>--------------------------------------------------------------------
>Repeat after me: Euro is Unicode position: U+20AC not U+20A0.
>Euro is U+20AC. Euro is U+20AC. Euro is U+20AC. Euro is U+20AC.
>Euro is U+20AC. Euro is U+20AC. Euro is U+20AC. Euro is U+20AC.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:40 EDT