On Jan 27, 2012, at 8:30 AM, Joerg Schilling wrote:

> "Garrett D'Amore" <[email protected]> wrote:
> 
>>>> This problems existed before -- e.g. what if someone was using a different 
>>>> 8859 standard (e.g. in Russia.)  The fact that their program, or yours, 
>>>> assumed that 8859-1 was in use, was a bad assumption.
>>> 
>>> So you like to tell us that you did not understand that the CD standardized 
>>> the 
>>> 8859-1 coding?
>> 
>> No.  You misunderstand.  The bad assumption is not that 8859-1 would be 
>> encoded on the disk, but that the operator was using an 8859-1 locale as his 
>> current locale.   I should be able to use these programs to create for a CD 
>> in 8859-1, even if I'm running in e.g. KOI8-R.  This problem is what 
>> libiconv was designed for.
> 
> Thank you for proving that you missunderstand things.

I don't,  but you aren't understanding me.

> 
> CD-Text is standardized in either 8859-1 or in a proprietary japanese coding 
> only. Cdrecord expects CD-Text files in the standard coding and it is the 
> duty 
> of other software to provide the CD-text in the right coding regardless in 
> what 
> locale they are running.
> 
> In other words: you cannot have russion characters in CD-Text.

Obviously.  Violent agreement here.

> 
> This is why I agree with the statement that UNICODE introduced problems that 
> did not exists before.

This is not Unicode's fault.  Other encodings existed before Unicode. 

Do you propose to suggest that I shouldn't be permitted to create a CD text 
label even though my login locale might be in RU.ISO-8859-2 ?    No.  The 
problem is that the software that is creating the text file needs to understand 
that it may need to do the conversion from whatever the locale it is operating 
in, to 8859-1 (or I suppose the Japanese encoding).

The fault is in the software that assumed login locale == 8859-1. 

Unicode just added another dimension to this, and allowed software which used 
to run primarily in 8859-1 (perhaps because that is the encoding formerly used 
by the majority of its users) to break when run in Unicode.  The same software 
was broken in 8859-2, KOI8-R, or any other encoding other than 8859-1 (or C, I 
suppose, as 8859-1 is a strict superset of C.)

        - Garrett


> 
> Jörg
> 
> -- 
> EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
>       [email protected]                (uni)  
>       [email protected] (work) Blog: 
> http://schily.blogspot.com/
> URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
> 
> 
> -------------------------------------------
> illumos-discuss
> Archives: https://www.listbox.com/member/archive/182180/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/182180/22003744-45f01c1f
> Modify Your Subscription: https://www.listbox.com/member/?&;
> Powered by Listbox: http://www.listbox.com



-------------------------------------------
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be
Modify Your Subscription: 
https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4
Powered by Listbox: http://www.listbox.com

Reply via email to