<SMITHM@QUCDN.QueensU.CA> (11/22/90)
I've been messing around with Blue Book program #16, "Making an Outline Font". The author goes to considerable pains to add a UniqueId entry to the fonts created. His/Her comments state: "Determine the [font's] unique ID. If the "base" font already contains a unique ID, add a unique constant to it, otherwise pick a unique integer and leave that value on the stack." Now, in reading these comments, I wondered how I would pick the "unique constant". (The author used 1 and 2 for the two fonts created.) Anyway, I wrote a program to list the names and UniqueId fields of all the resident fonts. To my surprise, *none* of the fonts on the LaserWriter II NTX had UniqueId defined. So this begs the question, do I really need to stuff a UniqueId into my outline fonts? Mike Smith SMITHM@QUCDN.BITNET Queen's University Michael.D.Smith@QueensU.CA Computing and Communications Services (613) 545-2024
SMITHM@QUCDN.QueensU.CA (11/23/90)
Thanks to James Farrow for pointing out that the name is UniqueID not UniqueId. It isn't Thanksgiving here in Canada but I do feel like a turkey... I've now listed the UniqueIDs on two printers, one with Adobe fonts and one with Imagen (UltraScript) fonts. At the risk of embarassing myself further, I'd still like to know how UniqueID is used. The Green Book program assumes that it is generating a unique ID by adding 1 to the base font's ID. This is true for the font in the example (Helvetica-Bold). It wouldn't work for Century Schoolbook Bold Italic because its ID is one less than Century Schoolbook Bold. What happens if I generate a UniqueID that isn't unique? As far as I can see, the only way to guarantee uniqueness is to maintain a list of all the IDs in use. Obviously this can be done but it seems like a lot of trouble. The Red Book says that UniqueID is not necessarily present in all fonts. Would I be better off to leave UniqueID out of my fonts if I'm not willing to guarantee uniqueness? Mike Smith SMITHM@QUCDN.BITNET Queen's University Michael.D.Smith@QueensU.CA Computing and Communications Services (613) 545-2024
pgd@bbt.se (11/25/90)
In article <90327.103524SMITHM@QUCDN.QueensU.CA> SMITHM@QUCDN.QueensU.CA writes: >What happens if I generate a UniqueID that isn't unique? UniqueID is for keeping track of the font cache. If you have two fonts with the same UniqueID, let's call them Font1 and Font2, they will be mixed up if both used. Let's say you first use Font1, character "A". After that you switch to Font2. If you then want character "A" from Font2, you will actually get the "A" from Font1 instead. You will get the character from whatever font that character was used first in. Cycling power, will reset the font cache, unless you have a hard disk in the printer. If you have that, you have to run a special program to clear the font cache. Sometimes when you are making a new font, and constantly are making changes, you might have to change the UniqueID after each font change, to get the new font, instead of the old, cached, one.
roy@phri.nyu.edu (Roy Smith) (11/26/90)
pgd@bbt.se writes: > UniqueID is for keeping track of the font cache. I guess this is sort of a "philosophy of PostScript" question, but why have the font designer/programmer supply the UniqueID at all? If the only reason it exists is to help the font cache, why not just have "definefont" make up its own UniqueID, presumably by hashing the font name? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy "Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"
<SMITHM@QUCDN.QueensU.CA> (11/26/90)
pgd@bbt.se writes: > If you have two fonts with the same UniqueID, let's call them Font1 > and Font2, they will be mixed up if both used. > Let's say you first use Font1, character "A". After that you switch to > Font2. If you then want character "A" from Font2, you will actually > get the "A" from Font1 instead. You will get the character from > whatever font that character was used first. This sounded a little scary so I tried the following test. I created an outline version of Helvetica that duplicated Helvetica's UniqueID. I then printed a line of text first in Helvetica Outline and then in Helvetica. There was no mixup in the fonts. (I power cycled the LaserWriter II NTX before my test to clear the font cache.) This test is simple minded but I'm tempted to conclude that I can duplicate the UniqueID field with impunity. At least, this appears to be the case if the two fonts differ only in PaintType. Mike Smith SMITHM@QUCDN.BITNET Queen's University Michael.D.Smith@QueensU.CA Computing and Communications Services (613) 545-2024
cet1@cl.cam.ac.uk (C.E. Thompson) (11/27/90)
In article <90327.103524SMITHM@QUCDN.QueensU.CA> SMITHM@QUCDN.QueensU.CA writes: >I've now listed the UniqueIDs on two printers, one with Adobe fonts >and one with Imagen (UltraScript) fonts. At the risk of embarassing myself >further, I'd still like to know how UniqueID is used. The Green Book >program assumes that it is generating a unique ID by adding 1 to the >base font's ID. This is true for the font in the example (Helvetica-Bold). >It wouldn't work for Century Schoolbook Bold Italic because its ID is one >less than Century Schoolbook Bold. I haven't got the Green Book to hand, but there are similar constructions in the Blue Book. There doesn't seem to be anything in the Red Book to suggest one should behave like this, but see remarks below on the relevance of the Black Book. (Gosh, I've mentioned all four of them!) On the first LaserWriter I tried I find that NewCenturySchlbk-Bold has UID 504 and NewCenturySchlbk-BoldItalic has UID 471, but it will depend on what versions of what fonts you have. I did find Palatino-Italic with UID 491 and Palatino-BoldItalic with UID 492, so differences of 1 certainly can occur. (BTW, AFM files from the Adobe fileserver seem to indicate that modern versions of the fonts have much larger UIDs, in the 28000+ range.) >What happens if I generate a UniqueID that isn't unique? As far as I can see, >the only way to guarantee uniqueness is to maintain a list of all the IDs in >use. Obviously this can be done but it seems like a lot of trouble. The Red >Book says that UniqueID is not necessarily present in all fonts. Would I be >better off to leave UniqueID out of my fonts if I'm not willing to guarantee >uniqueness? If you don't keep UniqueID's unique, you will be liable to pick up the wrong things from the font cache. UniqueID is never required, and if in any doubt it is better to undefine it. In this case the font cache entries will not survive the font disappearing from FontDirectory (e.g. at end of job), or at any rate they will never be used again and will be flushed out eventually. However: there would appear to be a difference here between type 3 fonts and type 1 fonts. For the former, there is just the one copy of UniqueID in the primary font directory; but for the latter there is also a copy in the "Private" directory. According to the Black Book (page 17) "if the UniqueID values are not present in both the font directory and Private directories, or if they have different values, then the font program is treated by the interpreter as if it had no UniqueID at all". Now if you are making a type 1 font by modifying one of the Adobe fonts in the style of the Green/Blue Book recipies, then you won't be able to modify the copy in the Private directory if you wanted to (as it is "noaccess"ed). So this would seem to mean that the prescription given is as good as unsetting UniqueID, in this case: it just isn't suitable for applying to a type 3 font. Anyexpert from Adobe care to comment? Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk
glenn@heaven.woodside.ca.us (Glenn Reid) (12/03/90)
In article <1990Nov26.174933.24043@cl.cam.ac.uk> cet1@cl.cam.ac.uk (C.E. Thompson) writes: >In article <90327.103524SMITHM@QUCDN.QueensU.CA> SMITHM@QUCDN.QueensU.CA writes: >> The Green Book >>program assumes that it is generating a unique ID by adding 1 to the >>base font's ID. This is true for the font in the example (Helvetica-Bold). >>It wouldn't work for Century Schoolbook Bold Italic because its ID is one >>less than Century Schoolbook Bold. Well, since I was responsible for writing that code, I suppose I should respond. My recollection is that the font cache uses both the font name and the UniqueID, not just the UniqueID, so adding one works okay, even if the UniqueID happens to match another font (with a different name). I recall testing it, in any case, and not running into any problems, but that doesn't mean that it's actually the right thing to do. I always thought it would be great to be able to flip the sign of the UniqueID, so it's still the same number, but it becomes negative if you modify it, but it's an unsigned value (besides, it wouldn't nest very well for repeated derivative fonts). I've never really seen precise documentation on this, however, and there is certainly a lot of voodoo surrounding generation of UniqueID values. It is getting increasingly important for all of us to understand it and do the right thing, though, as there are more and more fonts in the world every day, and some even have the same PostScript names as each other, from what I'm told. Glenn Reid