🚀 go-pugleaf

The following arose out of some e-mail exchanged with Andy Walker
<anw@uk.ac.nott.maths>, who recently posted a PostScript Type 3 chess
font containing

    /UniqueID 472474 def

I asked him how he had come to assign this value, and he admitted that
it was a telephone number!

I take it that most readers of this newsgroup are aware of the purpose
of UniqueID values. I will quote without permission from the new LRM
(pp.283-284):

> If a font has a unique ID, the interpreter can recognize that the
> cached characters belong to that font, even if the font dictionary
> itself is removed from VM and is later reloaded (by a subsequent job,
> for instance). If a font does not have a unique ID, the interpreter
> can recognize cached characters for that font only while it remains in
> VM. When the font is removed, the cached characters must be discarded.
>
> Correct management of unique IDs is essential to ensure predictable
> behavior. If two fonts have the same unique ID but produce characters
> with different appearances when executed, it is unpredictable which
> characters will appear when those fonts are used. Therefore, unique
> IDs must be assigned systematically from some central registry.

Note that the unpredictability being talked about is not restricted
to the current job.

The trouble is that the `central registry' mechanism would appear not
to exist for UniqueID values in Type 3 fonts. What we do have is the
following:

1. For UniqueID values in Type 1 fonts, Adobe maintain a central
   registry; moreover the range 4000000 to 4999999 is explicitly
   `reserved for private interchange in closed environments'. This
   was first documented in the Black-and-White Book `Adobe Type 1
   Font Format', it is repeated in the new LRM.

2. In level 2 PostScript, fonts (Type 1 or Type 3; also forms and
   patterns) can have XUIDs instead of UniqueIDs; these are arrays
   of integers organised for hierarchically devolved assignment. The
   values of the first component are to be assigned by Adobe, and
   the value 1000000 is `reserved for private interchange in closed
   environments'. This is documented in the new LRM.

However, until level 2 implementations exist (or if one wants to make
fonts that will continue to exhibit optimised caching behavior when used
with level 1 PostScript interpreters) one has to use UniqueID values
for Type 3 fonts: these values form an independent space from that
of UniqueID values for Type 1 fonts, and Adobe has apparently never
attempted to provide a central register for them. The effect of this
is that the entire range of values has to be treated as `reserved for
private interchange in closed environments'.

Is there any hope of rectifying this situation? For example, one could
imagine trying to use the same rules as apply to Type 1 font UniqueIDs
(quite natural in contexts in which Type 3 fonts might one day become
Type 1 instead). Unfortunately, because UniqueIDs were documented
(after a fashion) in the old LRM, without any suggestions as to how
make disciplined use of them, any such rules that one might want
to enforce are already being violated, with a clear conscience, by
someone, somewhere.

As things stand, I think that people posting (or otherwise making
publicly available) the source of Type 3 fonts should either avoid
the use of /UniqueID altogether (it is, after all, never necessary) or
should comment out the setting and attach suitable warnings about it.

Chris Thompson
Cambridge University Computing Service
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk