Around 13 o'clock on Jul 10, Anthony Fok wrote:
I have been wondering: would OpenType technology be able to help solve this
issue, since OpenType allows multiple glyphs (for different target
language) for each character?
Not any better than the OS/2 codePageRange bits that we already have;
On Tue, Jul 09, 2002 at 11:06:46PM -0700, Keith Packard wrote:
Around 13 o'clock on Jul 10, Anthony Fok wrote:
I have been wondering: would OpenType technology be able to help solve this
issue, since OpenType allows multiple glyphs (for different target
language) for each character?
On Tue, Jul 09, 2002 at 11:00:58PM -0700, Keith Packard wrote:
Around 13 o'clock on Jul 10, Anthony Fok wrote:
Just to clarify the current situation: while the GB18030 encoding covers
the entire Unicode codepoints, the current GB18030 standard does not
mandate or specify any characters
Yao Zhang wrote:
...
The only way to find out which Han variant one font has is by
looking at it.
When you say looking at it do you mean actually having a
human view the glyphs?
As long as we can configure it properly, zh_CN, zh_HK and zh_TW
etc really do not matter.
What do you
On Mon, Jul 08, 2002 at 06:42:37AM +1000, Roger So wrote:
On Mon, 2002-07-08 at 05:38, Keith Packard wrote:
Because the font does completely cover the expected encoding, it will at
least avoid the problem of ransom-note typography where glyphs from
several incomplete fonts are mixed
On Sun, Jul 07, 2002 at 10:52:35PM -0700, Keith Packard wrote:
Then the goal should be to identify GB18030 fonts as only zh-cn. For
users who have only a GB18030 font and no traditional Chinese fonts, the
zh-cn mark will cause that font to be preferred over a Japanese or Korean
font,
Around 13 o'clock on Jul 10, Anthony Fok wrote:
Just to clarify the current situation: while the GB18030 encoding covers
the entire Unicode codepoints, the current GB18030 standard does not
mandate or specify any characters in the CJK Unified Ideographs Extension
B, in which contains some
Around 15 o'clock on Jul 8, Roger So wrote:
A guy from the IT department of the HK Government was in the discussion,
and he stated that the official plan is to provide support for the PUA
entries as an interim measure, until the whole system is ready to
migrate to use non-BMP entries:
...
On Mon, 8 Jul 2002, Edward Lee wrote:
There are `two' Traditional Chinese fonts here. In zh-tw the
radical/stroke of some glyphs are differrent with the TC glyphs
in GB18030 fonts.
Could you give Unicode code points of a few of those characters?
Have you checked them out at your own
On Mon, Jul 08, 2002, Jungshik Shin wrote:
On Mon, 8 Jul 2002, Edward Lee wrote:
There are `two' Traditional Chinese fonts here. In zh-tw the
radical/stroke of some glyphs are differrent with the TC glyphs
in GB18030 fonts.
Could you give Unicode code points of a few of those
On Sun, 7 Jul 2002, Keith Packard wrote:
http://www.info.gov.hk/digital21/eng/hkscs/download.html
Thanks. I notice that the newest part of this table references quite a
few symbols beyond the BMP; would you suggest that I use the older
entries? Or should I use the non-BMP entries and
On Mon, 2002-07-08 at 16:30, Keith Packard wrote:
Let me rephrase the question in the context of this discussion -- in
attempting to identify which languages a given font is suitable for, I
believe I shouldn't expect fonts designed for HKSCS to support the non-BMP
encodings, and so
On Mon, 2002-07-08 at 19:18, Edward Lee wrote:
The examples are U+89D2(Big5 0xa8a4), U+904E(Big5 0xb94c),
U+9AA8(Big5 0xb0a9), U+5433(Big5 0xa764),
...
Thanks; I wasn't aware of the difference. (Our font supplier didn't
supply us with a true GB18030 font
On Sat, 2002-07-06 at 13:34, Keith Packard wrote:
My plan is to have fonts advertise the complete set of languages that they
cover, and then to allow them to further distinguish languages with
country codes as needed (zh-TW vs zh-CN).
Now matching can take place using the language tags;
Around 23 o'clock on Jul 7, Roger So wrote:
Certainly; but have you considered the case that zh-HK and zh-MO users
prefer zh-TW fonts over zh-CN fonts, and vice versa for zh-SG? (What
other Chinese-speaking regions are there... perhaps zh-MY?)
Yes, each language-country pair may specify
Roger So wrote:
And of course, many fonts from China now cover most characters defined
in GB18030, which means if using coverage tables, these fonts will
appear to support both zh-CN and zh-TW...
Why appear to ?
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL
Around 6 o'clock on Jul 8, Roger So wrote:
Actually, if the font is a proper certified GB18030 font, then
simplified characters will have simplified glyphs, and traditional
characters traditional glyphs. (Han unification didn't unify simplified
and traditional characters, fortunately [or
On Sun, 7 Jul 2002, Keith Packard wrote:
The question is whether we should mark certified GB18030 fonts as suitable
for zh-TW as well as zh-CN. I have the GB18030 varient of SimSun here in
TrueType and it does not have the traditional Chinese codePageRange bit
set, but does cover the
On Sun, Jul 07, 2002, Keith Packard wrote:
Actually, if the font is a proper certified GB18030 font, then
simplified characters will have simplified glyphs, and traditional
characters traditional glyphs. (Han unification didn't unify simplified
and traditional characters, fortunately [or
Around 12 o'clock on Jul 8, Edward Lee wrote:
The question is whether we should mark certified GB18030 fonts as suitable
for zh-TW as well as zh-CN. I have the GB18030 varient of SimSun here in
TrueType and it does not have the traditional Chinese codePageRange bit
set, but does
I've decided that using RFC 3066 to indicate font language coverage is a
good idea (or at least the best idea). Owen Taylor is partially
responsible as he's using it in Pango; the realization that HTML also
uses this RFC for language tagging documents makes it pretty clear that I
could do a
21 matches
Mail list logo
