[comp.lang.postscript] UniqueID values

cet1@cl.cam.ac.uk (C.E. Thompson) (03/28/91)

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

stephenf@suite.sw.oz.au (Stephen Frede) (04/02/91)

The idea of using a phone number as a unique value in
situations where there is no central registry is not
such a bad idea. Of course you should include your country
and area code, and can then append suffixes for as many
fonts as your organisation produces. Much better than
currency serial numbers (very parochial).

The only problems are when you change your phone number,
and the fact that in the case of UniqueID, the range is
only up to 2^24-1.

			Regards,

				- Stephen Frede

Softway Pty Ltd, P.O. Box 305, Strawberry Hills, NSW 2012, AUSTRALIA
Phone: +61 2 698 2322; Fax: +61 2 699 9174; Telex: AA27987
domain: stephenf@softway.sw.oz.au  UUCP: ...!uunet!softway.sw.oz!stephenf