[Gs-devel] multi-dimensional range comparator patch for new CMap handler (Re: new CMap handler has several bugs and instability.)

[Igor V. Melichev]

Dear Mr. Suzuki,

> From: mpsuzuki at hiroshima-u.ac.jp
> Sent: 11 ?????  2001 ?. 07:22
> To: igor at artifex.com
> Cc: raph at acm.org; gs-devel at ghostscript.com
Su> bject: about OCF (Re: "rearranged font" CMap operators)

> Quite sorry, I will remake the patch as soon as possible.

I would be happy to get modified files, not the patch.

> The latest Cygwin is compatible with your environment?

I am unhappy of this tool. Yes, it works, but I prefer visual
technology - such as Windiff by Microsoft - it visualizes changes
much better. Besides, you did not specify version numbers of original files
you worked with - specifying dates may cause errors.

Also I would very appreciate if you send tests for your patch.

> >it looks that I missed
> >about ligatures...
>
> Me too :-). Yamada-san found this feature from Unicode CMap,

Does Adobe document this ?
Can you send this CMap to me ?

My server can pass 10M in one message.

> >By the way, some Adobe's implementations convert some
> >CIDFont-CMap into OCF format while loading.
> >Adobe calls this "OCF compatibility".
> >Since you live in CJK world, maybe you can answer my old questions :
> >
> >- is OCF compatibility still actual ?
>
> Hmm, although Adobe announces OCF will be disabled in future,
> and most font vendors do not sell OCF anymore, still PS printers
> /CPSI/DPS keep the functionalities to use OCF. We can use FMapType0-8.
>
> # Why Adobe still supports OCF? It's not clear.

I'm sorry, this is not what I'm asking about.
Before starting my work for Artifex, I did multiple things with CPSI,
including analysis of its CID font machinery. I discovered that
it supports "OCF compatibility". I don't remember all details now, but
likely it converts CIDFont-CMap into OCF format, if CMap
belongs to the following list :

/H/V/B5pc-H/B5pc-V/GBpc-EUC-H
/GBpc-EUC-V/78ms-RKSJ-H/78ms-RKSJ-V/83pv-RKSJ-H/90ms-RKSJ-H/90ms-RKSJ-V
/90pv-RKSJ-H/Ext-H/Ext-V/Ext-RKSJ-H/Ext-RKSJ-V/RKSJ-H/RKSJ-V
/Roman

Since CPSI can handle both OCF and CIDFont-CMap, CPSI is not the reason
for the conversion. As well as other interpreters.
I guess the reason is some old PS documents.
Possibly some old documents access font internals, supposing it is OCF,
and the "OCF compatibility" is a method to replace old fonts
with new achievements, keeping the maintenance of the old documents.

Thus, my question may sound as this : did you ever meet documents,
which require exactly OCF ? Is they still actual to support ?

> >Perhaps I'll rewrite Type 1 hinter soon (I believe it is
>
> Hmmm! Yes, no problem will be arise (rather, I should do so).
> Rewriting of Type1 hinter sounds much interesting.
> It makes me remember the gsft project by Mr. Zappa,
> his work will be adopted?

I studied sources of FreeType, XFree86, t1lib. All them generate different
output
than Adobe. gsft is a bridge from gs to FreeType, right ?
No, I don't adopt it. My intention is to achieve maximal
Adobe compatibility. I'm doing this with testing Adobe's products and
studying Adobe's manuals.
My main discovery is that Adobe RIP doesn't follow Adobe's specs.
I've got some progress in the last year, but then this project was delayed.
I believe we'll resume it soon.

Igor.