Article View: comp.lang.postscript
Article #7372Re: PostScript compatible printers
From: Glenn Reid
Date: Tue, 09 Aug 1988 00:36
Date: Tue, 09 Aug 1988 00:36
174 lines
9701 bytes
9701 bytes
> > > Adobe fonts are not part of PostScript.
> > This I don't understand.
>
> Read the red book. The format of the font files is not specified. In
> fact, it is not even specified that outline fonts have to be used at
> all, although it mentions that Adobe's implementation does use them.
> In the appendix, Adobe mentions a standard set of core fonts, but even
> these are not part of the language.
>
> This is not to say that we are splitting hairs. We wouldn't be in
> business if we did. IMAGEN's fonts look just like Adobe's fonts, since
> they come from the same outline data. I think that the user wins in
> this situation. Disk space is a problem if you have to store both
> IMAGEN and Adobe fonts on a disk, but a font in all its sizes fits in
> about 55KB, which is small potatoes with current disk prices. Many
> IMAGEN printers have hard disks on them, so you don't need to store the
> fonts on your local system, or download, etc..
>
> - Geof
> --
> {decwrl,sun,saber}!imagen!geof
The PostScript language (as specified in the "red book") has very
specific mention of fonts and their format; it is chapter 5 in my
book. Basically, fonts are dictionaries with very specific contents
intended for use by the font machinery. This is all documented.
"Adobe fonts" have become an enigma which perhaps needs some
clarification.... You can think of fonts from two points of view: as
the interpreter, or as the user. Let's look at them both, and let's
look at them through the "compatibility" lens.
THE USER'S POINT OF VIEW
------------------------
From the user's point of view there are only three things
about fonts that really make any difference (heavy-handed
generalization follows):
1. Character widths, for accurate typesetting.
2. Character shapes (the visual appearance of the text).
3. The font names.
The way device independence for fonts works is that you ask for the
font by name and point size, and the interpreter draws the characters
for you. If you like the way it looks, and you can lay out the text
exactly the way you want it, then you're happy.
The fact that you ask for fonts by name is very interesting. If you
send the program "/Times-Roman findfont" down to your printer, you are
asking for a specific, trademarked font name. I believe that if you
ask for a font using Linotype's name and you get a font made by
somebody else, then that somebody is treading on thin copyright ice,
but I am certainly not an authority on such matters.
In any case, the same document description sent to different printers
should yield the same results. This is where character widths are so
important. If even a single character's width is off by a single
printer's point, a fully "justified" column of text will end up "ragged
right" unintentionally. This makes you unhappy, if you're a user.
This all has nothing to do with the "implementation" of the fonts: if
you ask for a font by name and you get results that you are pleased
with, then (from the user's point of view) everything is compatible.
That is the idea behind PostScript in the first place, and that is why
the fonts will work (and can be made resident) in any of 30 or so
different PostScript printer products.
Assuming that a vendor licensed the fonts from Linotype (in the case of
Times Roman, at least) and assuming that there were no "bugs" or
incompatibilities in the character widths, and assuming that you like
the printed results, then that printer might be considered really
compatible. On a document-by-document basis, you can imagine that this
would have to be true for any and all fonts used in the document. This
brings us to the next point of view, since the way you get a font
loaded into a printer is to get it past the interpreter.
FROM THE INTERPRETER'S POINT OF VIEW
------------------------------------
A "ROM-resident" font is an already-built PostScript language
dictionary data structure with a pointer to make it available by name
(like /Times-Roman). All other fonts (including those stored on the
printer's disk) can be considered "downloadable".
A downloadable font is just a program written in the PostScript
language. Typically what these programs do is to construct a
dictionary data structure and fill it up with little procedures to draw
characters, then call the "definefont" operator to register it under a
particular font name. All of this is done in accordance with the
guidelines set forth in the "red book". There are, in fact, several
third-party font vendors who have downloadable font products that can
be loaded into all Adobe PostScript printers (Altsys' Macintosh-based
Fontographer product, for instance).
The "Adobe" downloadable fonts are, in fact, just PostScript programs.
They are encrypted, however, as a mechanism for protecting the font
outlines themselves which we have licensed from various typeface
companies. That is what the "eexec" operator does (encrypted exec).
The idea is to keep the programs themselves from being visible. After
all, the typeface itself is not protected under copyright law, only the
name. The font vendors have a vested interest in keeping the outline
data in a protected form.
Adobe downloadable fonts simply will not download into a printer which
cannot decrypt them. If the "eexec" operator is not present (or if it
is not functional) the font programs will not execute correctly. Other
downloadable fonts, however should (in theory) work correctly.
Any font program can be stored on a printer's disk as a downloadable
font program, and in fact Adobe's downloader checks to see if your
printer has a disk and lets you download it there if it does. They
might also be available out on the network on a font server, available
dynamically when "findfont" is executed. Where the font "lives" is
not really an issue, only whether they are available at all, and
whether or not they execute successfully.
CONCLUSIONS (if any)
--------------------
To say that "Adobe fonts are not part of PostScript" is a two-edged
statement. In one sense, it is correct to say that any particular font
is not part of the language definition. They might be thought of as
"resources" that are available to the page description program. On the
other hand, the whole point of PostScript is that a program that will
run on one printer will run on another, and that includes fonts. Any
program that includes a downloadable font in-line will not run on a
printer that can't handle the encrypted fonts. Any program that makes
reference (by name) to a font that is not available could be considered
not to run on that printer. Since fonts can be made dynamically
available, that is a tricky area (I have printed lots of documents,
unfortunately, for which the fonts were not available). Most useful
document processing software will download fonts for you if they are
not available in the printer. If these fonts are "Adobe" fonts, then
they will likely only run on Adobe interpreters. They may not be "part
of the language", but they sure are part of the document.
You can think of Adobe as having two independent products: we sell
printer technology, which contains the PostScript language interpreter;
wej also sell downloadable typefaces, which are a product line that is
NOT documented in the Red Book. It is documented in our Font Catalog.
The fact that these font products only run on Adobe printers is
significant. Everybody else's downloadable fonts only work on their
printers, too, perhaps because nobody has bothered to "clone" the
printers (and because they are bitmapped fonts, in general, which means
they are resolution-specific), not because the format is protected.
When looking at the compatibility of a printer, look at it from the
document's point of view. If the document uses "Hobo" or "Eras" or
"Univers", then your printer has to have it. If it is not available
built into the printer, then it has to be downloaded. If the typeface
was licensed from a typeface manufacturer, the downloadable font will
very likely be in some protected format or another. Adobe has solved
this problem and licensed it to 26 different printer manufacturers for
inclusion in well over 30 different products, and already has over 250
different typefaces in the growing library. Linotype Corporation has
actually licensed our font-making technology and is producing their own
additional "Adobe" fonts (using the same encryption scheme) as part of
the total available (and compatible) library of fonts. Also, Digital
Equipment Corporation, NeXT, and Scitex have also licensed Adobe
interpreters for Display PostScript, gaining instant compatibility with
the entire library of PostScript fonts.
I hope this helps somewhat. Fonts really are a product of ours, not
just part of the language definition. If you want to use our font
library, you have to buy one of our many OEMs' printers. It's at least
simple, if not entirely agreeable to everybody.
Thanks for listening this far,
Glenn Reid
Adobe Systems Incorporated
Technical Details
Message-ID:
<4145@adobe.COM>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!decwrl!adobe!ondine!greidReferences:
<5122@gryphon.CTS.COM> <1777@imagen.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!decwrl!adobe!ondine!greid From: greid@ondine.COM (Glenn Reid) Newsgroups: comp.lang.postscript,comp.fonts Subject: Re: PostScript compatible printers Message-ID: <4145@adobe.COM> Date: 9 Aug 88 00:36:35 GMT References: <5122@gryphon.CTS.COM> <1777@imagen.UUCP> Sender: news@adobe.COM Reply-To: greid@ondine.UUCP (Glenn Reid) Organization: Adobe Systems Incorporated, Mountain View Lines: 173