[gs-devel] RE: porting gs-cjk to HEAD (Re: gs-cjk jumbo patch candidate for GS_7_0X branch)

[Igor V. Melichev]

Dear Mr. Toshia Suzuki,

> From: mpsuzuki at hiroshima-u.ac.jp
> Sent: 3 ?????  2002 ?. 18:11
> To: igor at artifex.com
> Cc: raph at levien.com; gs-devel at ghostscript.com;
> mpsuzuki at hiroshima-u.ac.jp
> Subject: porting gs-cjk to HEAD (Re: gs-cjk jumbo patch candidate for
GS_7_0X branch)

> Due to working for gs6.53 & gs7.05, I've been detached
> from HEAD for long time and now unfamiliar with font
> environment in HEAD. Before porting to HEAD I have to
> come up with it.

OK.

>I think it should start with accommodating patches
>which is not related to TrueType to CIDFont substitution.

> I agree. In gs-cjk patches, they are rather smaller bits,
> not difficult to port. But I've never used FAPI plugin,
> so I'm not sure if there's no unexpected bad subeffects.
> How can I check - or who can I ask for testing - without
> bothering you?

You don't need to test FAPI. You only need to accommodate
the "CID font substitution with True Type" to work through
gs_resmp.ps, gs_cidfm.ps .


> >Also my strong opinion is that the processing of 'gsub'
> >must go to C code rather than PS, at least for compatibility
> >with FAPI.
>
> Hmm, current GSUB parser in gs_ttf.ps is basically written
> to pickup glyphs for vertical writing mode, so it's not
> GSUB parser in exact meaning. If Ghostscript is going to have
> (or import) generic API and operators to access tables in
> TrueType, TrueType GX, TrueType Open and OpenType, I'm interested
> in using them in gs_ttf.ps. FAPI provides such tools?

In my view, gsub processing is an internal work of
a TrueType font renderer, at least because gsub is TrueType specific.
UFST does this internally, depending on the writing mode.
FAPI is a more general thing which now attaches UFST and
will attach FreeType someday.

gs-cjk creates an inverse CMap "concatenated" with gsub.
 gs_ciddc.ps already has a code for inverse CMap, but with no gsub.
I'd like to see gs_ciddc.ps and FAPI as a thing independent on the renderer,
otherwise we need to generate 2 different versions of the inverse CMap - for
gs-cjk and for FAPI,
and keep them both in RAM if both renderers work in same time.

> However, CJK TTF loader in gs_ttf.ps was written by Taiji Yamada
> and Hideyuki Suzuki - not by me, and I heard Taiji is going to
> improve CJK TTF loader more, so I have to ask their opinions and
> discuss with them.

Please transfer my information to them and discuss it.
Also please note that FreeType team works with us on the
integration of FreeType with GS (now it is in design phase).

Igor.