[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] Re: IDNA: is the specification proper, adequate, and complete?



Copy&Paste operations from  such legacy applications into other applications
may not preserve the intended character glyph informations  determined by  char sets+font sets.
That will pose another interoperablility problems to end users.

Some OS-addon/applications has it own proprietary legacy char set/locale, but share the same code space with ASCII
and use ASCII-mapped font-substitution to implement their legacy char sets, for example, in order to
implement CJK supports in English-only windows or linux. I found some other examples in Indic char sets.
 
In General, informations about assumed/system-wide font sets  
  are not available to applications  or not interpretable  with machine intelligence.

These kinds of font usages should be discouraged in IDN specifications ?

Soobok Lee

----- Original Message ----- 
From: "Soobok Lee" <lsb@postel.co.kr>
 > Subject: Re: [idn] Re: IDNA: is the specification proper, adequate, and complete?
> 
> 
> > Mark Davis <mark at macchiato dot com> wrote:
> >
> > > 2. There are no "non-Unicode coding systems" that unify beta and
> > > eszed; the language issue is irrelevant.
> >
> > MS-DOS code page 437 had a character at 0xE1 that was sometimes rendered
> > more like a sharp-s and sometimes more like a small beta, depending on
> > which screen font you were using.  In the standard 8x8 font and 8x14
> > fonts it was very definitely a beta, but in the 8x16 font it was a
> > sharp-s.
> 
> One similar example in TC/SC:
> 
>   One of the most popular korean word processor "Arae-A Hangeul" (not unicode-based)
>      provides with two chinese font sets, one for TC and the other for SC.
>   If a Korean user wanna write a letter in SC that may contain  IRI or IDN,
>    he should type  it in TC first and change the session font set into  given SC font.
>   Then, most 1:1 TC letter is displayed/printed as its SC equivalent.
> 
>   Most Koreans are not familar to exotic Input Methods of Japanese and Chinese Simplified
>   letters. Facilitating input of exotic chars by font substitutions has merits.  That remind me of
>   the ASCII-mapped DINGBATS font sets.  I don't know well
>   about whether or not   there are similar cases in japan , taiwan and china.
> 
>  Soobok Lee
> 
> 
> 
> 
> 
> 
>