[gs-bugs] [Bug 691274] Missing or incorrect ToUnicode when using Identity ordering

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Mon May 3 10:31:29 UTC 2010


--- Comment #7 from Ken Sharp <ken.sharp at artifex.com> 2010-05-03 10:31:28 UTC ---
(In reply to comment #6)

> > /MyFont /Identity-H /CMap findresource
> >  [ /ArialUni /CIDFont findresource ] composefont pop
> I'm not sure how to use the "definefont" operator to create a composite font;
> would it be ok to use "composefont" instead?

I'm doubtful, but it might work. To add the dictionary to an existing font you
simply need to copy all the contents of the existing font dictionary, add the
GlyphNames2Unicode dictionary to the copied FontInfo dictionary and execute
definefont (remembering also to alter the FontName, and UIDs if present).

> I was thinking about something
> like this:

That may work, I haven't tried it. As long as composefont copies all the
contents of the FontInfo dictionary from the CIDFont to the type 0 font, then
it should be fine, and its a good way to proceed. 

I don't know off-hand whether pdfwrite extracts the GlyphNames2Unicode
information from the parent type 0 font created by composefont, or whether it
expects to find a GlyphNames2Unicode dictionary in each of the descendant
fonts. I would guess the former though. This is where this approach may fail,
if composefont does not copy the GlyphNames2Unicode dictioanry, or does not
copy it into the correct place(s).

> I noticed that I need to switch to global VM mode in order to be able to save
> the entry in the font dictionary. I assume that the new copy will also need to
> be saved in global VM, is that right?

You can save global objects in local VM, you can't save local objects in global
VM, see the PostScript Language Reference Manual, page 60 in my edition.

I presume the font dictionary is defined in global VM, which means the FontInfo
dictionary is also in global VM, which means any composite objects (such as
dictionaries) that you want to store in the FontInfo dictionary must also be in
global VM.

Of course if you copy the contents of the font dictionary the new font
dictionary, and its contents, need not be in global VM. Fonts are often treated
as a special case because you normally expect them to persist for the life of
the PostScript program, so they are normally defined in global VM, but its not

> I also noticed that I cannot use the "defineresource" operator to define my new
> dictionary  as a CMap resource, because the value of 2 is not regarded as a
> valid CMapType value by the PostScript interpreter, it seems. Maybe the
> ToUnicode CMap does not need to be associated with the "CMap" name?

The ToUnicode CMap shouldn't exist on the PostScript side. This CMap is created
from the GlyphNames2Unicode dictionary in the FontInfo dictioanry (if present)
by the pdfwrite device.

The only CMap you need is the one you use as the argument to composefont to
create the CID-keyed instance. I would imagine you want one of the supplied
Identity or Unicode mappings, possibly Identity-UTF16-H though I notice you are
using Identity-H in the example above.

In PostScript the only valid CMap types are 0 or 1, type 2 is a PDF-only
'ToUnicode' map type.

> It will probably take me a while to figure out how to do the copy. As I
> understand, the copy operator only makes a shallow copy. Maybe there is some
> other way to do it, that I have not thought about?

You need to use forall to enumerate the contents of the font dictionary. For
each object in the font dictionary you can either shallow copy it, or for
composite objects (dictionaries, arrays) you can use forall again to make
copies of the contents of the object. I would think that almost everything you
need (as composite objects) could be simply 'copy'ed with the exception of the
FontInfo dictionary.

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list