Re: [ft-devel] Re: Preliminary support to CMap files on CID-keyed fonts.

[mpsuzuki]

Hi,

On Sat, 09 Sep 2006 09:14:56 +0200 (CEST)
Werner LEMBERG <address@hidden> wrote:
>Hidetoshi, three years ago you've sent a preliminary version of your
>CMap support to the list.  Today this is still missing in FreeType.
>Is there any progress?

A few months ago, I discussed with Masatake Yamato about this issue:
it should be finished soon (or not)? with Masatake Yamato. I thought,
there was a few remarkable changes around the FreeType2 and typographic
technology in OSS, after Hidetoshi's proposal.

I understand Hidetoshi's work was an intention to emulate TTF-like
properties in FT_Face, by builtin charcode-cid conversion with CMap.
If I'm misunderstanding, please correct me and discard following text.
In following, I note 2 points why I hesitate to start working.
Any comments are welcomed.

Regards,
mpsuzuki

--

(1) migration from CJK PS font to OpenType/CFF

When Hidetoshi posted his proposal, the popular CJK PS font was
CID-keyed PS font which has no interface for character code handling.
But, today, most commercial font vendors switched to sell OpenType/CFF
as replacement of CID-keyed PS font. Although CID-keyed PS font are
still sold, they are for PS printers & legacy RIP systems that was
not updated for OpenType/CFF. In free fonts, there is fontforge which
can convert CID-keyed PS font into OpenType/CFF. So, the requirement
for character code features by CMap is being less important, I suppose.
What kind of situation that emulation by CID-keyed PS font + CMap works
better than real OpenType/CFF? Only for legacy systems? Or, exact
handling of legacy encodings like 78-RKSJ-H, 78ms-RKSJ-H, 90ms-RKSJ-H
etc etc are required?

(2) FreeType2 does not handle OpenType layout

In Hidetoshi's post, he noted about GSUB emulation issue. Let me
explain again. When we create a TTF-style cmap from CJK PS font
by CMap, nothing to say, it cannot store various glyph variations
(for Adobe-Japan1, Japanese character code does not specify writing
direction, same character code point is used for horizontal & vertical
forms). Thus, to retain cid for glyph variations, GSUB emulation is
required. But FreeType2's FT_FaceRec has no member to convey such
information to clients. Pango, Qt and m17n libraries access OpenType
tables without FT2, therefore, even if FT2 provides GSUB emulation,
such libraries don't use it. Most of glyph variations which should
be specified by OpenType extension will be lost. To avoid such
inconsistency (FT2 reports a font file as OpenType, but when a client
accesses the file, it is CID-keyed font, no OpenType tables, oops),
the font file conversion into OpenType/CFF is more simple solution,
I suppose. How can we solve this issue?