Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][no subject]
- Date: Thu, 10 Oct 2002 14:46:52 +1000 (EST)
- From: Jim Breen <jwb@example.com>
Catching up with some email.... >> Date: Wed, 25 Sep 2002 18:03:08 +0900 >> From: Stephen Lee <sl@example.com> >> Jim Breen <jwb@example.com> wrote: >> > >> From: Ulrich Plate <plate@example.com> >> > >> Or is it still possible to >> > >> match Chinese and Japanese rendering styles in a Unicoded document >> > >> within a single font, provided the text declares the language tag >> > >> correctly? >> > >> > Well, not with a single font. >> >> It could be desirable to use the same font and have a consistent look in >> a document that e.g. mixes Chinese and Japanese. To be frank, I don't see this as desirable at all. Fonts are a means to achieving a particular display image, and I think a font/style is a better way to go. >> Technology-wise, a single font can support variant glyphs of a single >> character, although I have yet to see a good implementation. This is >> probably because I don't buy fonts, but considering how even a large >> company like MS have problems with having a consistent look between >> JIS-0208 and JIS-0212 characters, it will take a lot of effort to >> achieve a single CJK font. >> >> Here's proof that a font can contain variants, from someone you know >> well :-) >> >> http://www.unicode.org/iuc/iuc13/a10/slides.pdf I don't really agree with Ken on this. I think glyph substitution tables are a disaster waiting to happen. Anyway, Ken is talking more about things like 学 <-> 學 mappings, which is more one of character variant rather than strict glyph. What I meant is the issue of "Chinese-style" characters vs "Japanese-style" characters. Often the stroke are the same, and it comes down to things like the placement of the kusakanmuri element, etc. >> Unicode 3.1 have code points for language tags, but their use is >> strongly discouraged: >> >> http://www.unicode.org/unicode/reports/tr27/#tag >> >> "The characters in this block provide a mechanism for language tagging >> in Unicode plain text. However, the use of these characters is strongly >> discouraged. The characters in this block are reserved for use with >> special protocols. They are not to be used in the absence of such >> protocols, or with any protocols that provide alternate means for >> language tagging, such as HTML or XML. The requirement for language >> information embedded in plain text data is often overstated. See Section >> 5.11, Language Information in Plain Text in The Unicode Standard, >> Version 3.0...." And I totally agree with their deprecation. Those language tag code points met with a lot of opposition, so it was a compromise to let them in then deprecate them. Jim -- Jim Breen (j.breen@example.com http://www.csse.monash.edu.au/~jwb/) Computer Science & Software Engineering, Tel: +61 3 9905 3298 P.O Box 26, Monash University, Clayton VIC 3800 Fax: +61 3 9905 5146 Australia (Monash Provider No. 00008C) ジム・ブリーン@モナシュ大学
- Follow-Ups:
- [tlug] i18n
- From: Tony Laszlo
Home | Main Index | Thread Index
- Prev by Date: Re: List Archives (was: Re: [tlug] MRTG without SNMP: how-to?)
- Next by Date: [tlug] Lessig's "Future of Ideas"
- Previous by thread: Re: List Archives (was: Re: [tlug] MRTG without SNMP: how-to?)
- Next by thread: [tlug] i18n
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links