Re: [Devel] CIDCMap support code (alpha version)

[Pavel Kankovsky]

On Thu, 18 Jul 2002, YAMANO-UCHI Hidetoshi wrote:

> Unicode is NOT encoding but ucs2 and ucs4 are encodings.

Yes. Unicode is a "coded character set" not a "(byte) encoding scheme".
But as far as I know FT API works with characters codes--code points,
not with encoded byte sequences. Perhaps "ft_encoding_" should read
"ft_coded_charset_"?

> And Microsoft Office XP Chinese Version and its Chinese Language Pack
> have included a TrueType font with ucs2 and ucs4 encodings.  When we
> use it, FT_Set_Charmap( ft_encoding_unicode ) returns ucs2 charmap not
> ucs4 charmap.
  
I suppose the purpose of having both cmaps is to make the font
(partially) usable by software not supporting new cmap formats allowing
code points >= 2^16. But "UCS2" cmap should always be a restricted version
of "UCS4" cmap (unless the font is completely broken) and the application
should not be bothered with a choice between them. I agree with Boris
that it is a bug when FT does not pick a "better" cmap when it is
available.

> > Would it make sense to support all this Babylonian mess of encodings?
> > The list of "native" encodings is pretty short and the rest would be
> > usable iff the application loaded a standalone cmap explicitly.
> 
> Oops, winfont and pcf fonts have many encodings.

Hmm...as far as I know winfonts (.fnt) have a list of ~10 magical numbers
(including a very generic OEM_CHARSET whose meaning is "whatever encoding/
c.c.s. used by the version of MS Windows this file was shipped with").
BDF and PCF can have an arbitrary string in their CHARSET_* properties 
but I do not think the number of widely used values is too high (my guess 
is 20-25).

> And I think ft_encoding_ is too depend to TTF specification and its
> definition is too ambiguous.

I agree.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."