From: mpsuzuki@hiroshima-u.ac.jp
Date: Mon May 21 2007 - 08:34:49 CDT
On Mon, 21 May 2007 12:56:07 +0200
"Philippe Verdy" <verdy_p@wanadoo.fr> wrote:
>mpsuzuki@hiroshima-u.ac.jp wrote:
>> Gerrit Sangel <z0idberg@gmx.de> wrote:
>> >If there were a way to store the information about
>> >the variation of the character in the text itself,
>> >I think, it would be possible to create a font
>> >to include all CJK characters?
>>
>> To include all CJK characters including glyphs for each
>> language, the number of glyph will be greater than 64k
>> (the size of CJK Unified Ideographs (inc. all Extensions)
>> is almost about 64k - if we collect non-unified variants
>> for CJKV, the number must be greater than a few times of
>> 64k). They cannot be packed into single TrueType/OpenType
>> font which has limitation of 64k glyphs. You will have
>> to implement new font format of larger character collection
>> and rasterizers, text render etc etc. I guess it is not
>> what you want.
>
>Given that the newer extensions for CJK ideographs will be introduced, how
>can a complete font for CJK be defined as it will need more than 64k
>characters even when storing a single variation?
I think so. For example, SURSONG.TTF of OfficeXP
for PRC market included 65530 glyphs (upto Ext. B),
it's impossible to insert Ext. C1 glyphs into there.
However, I'm not sure if the complete coverage of
CJK Unified Ideographs is seriously required.
Japan national body had registered the subset coverage
for Japanese market to ISO 10646, although it's
arguable whether it's really sufficient for Japanese
market. I wish if other CJK national body defines
the subset coverages for their market, to fit 16bit
glyph collection :-).
>Is the OTC extension for Opentype able to handle such case, by creating in a
>single font file multiple fonts packed together, and crosslinked with an
>explicit fallback from one font to the other in the same pack?
Excuse me, OTC is the OpenType/TrueType Collection
described in OpenType specification v1.4? If so,
I remember, it doesn't mention anything about the
relationship among the faces included in same package
(if I'm wrong, please correct). In fact, Microsoft
had ever used TTC to pack independent faces (think
about Courier & Helvetica) into single file, for
Japanese and Korean markets. There might be requirement
to use OTC for 32bit glyph collection, but I don't
know if there's any movement for standardization.
>If such extension is used, doesn't it help reduce the impact of the 64K
>glyph limitation and then allowsstoring multiple variants?
I'm sure it reduces the impact, but I'm not sure
if it's the best solution. Repeated switching of
the faces (from BMP face to SMP face, from SMP
face to BMP face, from...) can be some impact for
the system missing intelligent font cache.
>Or will it require changing the table formats for extendong the internal
>binary storage size for glyph id's?
I wish if we had real 32bit font format. But, at present,
the requirement of 32bit glyph collection in single font
is too small to invent new 32bit font format, I guess.
Regards,
mpsuzuki
This archive was generated by hypermail 2.1.5 : Mon May 21 2007 - 08:39:19 CDT