[comp.fonts] PostScript compatible printers

richard@gryphon.CTS.COM (Richard Sexton) (08/01/88)

In article <1755@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>
>Let us be fair.

Wake up. This is USENET.


:-)  if I really have to

>The reason is the US (and international) trademark laws.  "PostScript"
>is a trademark of Adobe systems, and they have sole control over the
>use of the name.  UltraScript (trademark by IMAGEN) was designed to be
>and <is> no more or less than PostScript; we refer to it (legally) as a
>PostScript compatible language.  Another way of saying this is that
>UltraScript interprets PostScript programs correctly.  The difference in
>names is the same one you see between IBM-PC's and the "compatibles."

>

>- Geof Cooper
>  Project Mudslide
>  IMAGEN Corporation, a subsidiary of QMS Inc.
>-- 
>{decwrl,sun,saber}!imagen!geof



So it works with Adobe fonts ?


-- 
                           AI is a shell game.
richard@gryphon.CTS.COM                               {backbone}!gryphon!richard

geof@imagen.UUCP (Geoffrey Cooper) (08/02/88)

In article <5090@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes:
> So it works with Adobe fonts ?

No.  Adobe fonts are not part of PostScript.  Look at News.

The answer is that we'll sell you fonts that are compatible with
Adobe's that do work.  Our font library is not yet as extensive as
theirs, but it is growing and should satisfy many users.  If it doesn't
satisfy you, sorry, enjoy your Adobe fonts and buy Adobe PostScript. 
Your QMS salesperson will be happy to oblige... :-)

- Geof Cooper
  IMAGEN Corp, a subsidiary of QMS inc.
-- 
{decwrl,sun,saber}!imagen!geof

richard@gryphon.CTS.COM (Richard Sexton) (08/03/88)

In article <1766@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>In article <5090@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes:
>> So it works with Adobe fonts ?
>
>No. 

This part I understand.

> Adobe fonts are not part of PostScript.

This I don't.

Adobe fonts may use secret stuff, but you cant really say they
arnt PostScipt ????

> Look at News.

They coldnt figure it out either, huh ?

>
>The answer is that we'll sell you fonts that are compatible with
>Adobe's that do work.  Our font library is not yet as extensive as
>theirs, but it is growing and should satisfy many users.  If it doesn't
>satisfy you, sorry, enjoy your Adobe fonts and buy Adobe PostScript. 
>Your QMS salesperson will be happy to oblige... :-)

Thats what I like about standards. So many to choose from. So what is your
font library ? Bitmaps ? Or are they outlines ? If the former, how
much space does one face take up on a disk, assuming you want a full
range of sizes from 6 to 800 (yes I use all those sizes)


I already use QMS printer, so my real intrest is how different companies
and handling font technology.

So far it looks like adobe wins hands down and everyone else is scrambling.


-- 
                           AI is a shell game.
richard@gryphon.CTS.COM                               {backbone}!gryphon!richard

ted@mitre-bedford.ARPA (Edward J. Ede) (08/04/88)

In article <5122@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
>In article <1766@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>>In article <5090@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes:
>> Adobe fonts are not part of PostScript.
>
>This I don't.
>
>Adobe fonts may use secret stuff, but you cant really say they
>arnt PostScipt ????

The PostScript page description language is in the public domain.
However, Adobe's fonts are loaded by the eexec operator, try to find a
description of that in the public domain.

>
>> Look at News.
>
>They coldnt figure it out either, huh ?

Great comeback...

>>The answer is that we'll sell you fonts that are compatible with
>>Adobe's that do work.  Our font library is not yet as extensive as
>>theirs, but it is growing and should satisfy many users.  If it doesn't
>>satisfy you, sorry, enjoy your Adobe fonts and buy Adobe PostScript. 
>>Your QMS salesperson will be happy to oblige... :-)
>
>Thats what I like about standards. So many to choose from. So what is your
>font library ? Bitmaps ? Or are they outlines ? If the former, how
>much space does one face take up on a disk, assuming you want a full
>range of sizes from 6 to 800 (yes I use all those sizes)

I posted an article about Imagen printers about 7-10 days ago.  Imagen
has licensing agreements with ITC and LINO similar to Adobe's.  The
fonts have the same name.  In speaking with the Imagen folk, they
don't necessarily agree with the look of Adobe's fonts, but they
intentionally don't change the look to remain compatible.  The fonts
are outlines, and I have a ton of room left for more on my 20 meg hard
disk in my printer controller :-)

Outline fonts are fine and dandy, but Imagen used bitmap fonts for
their imPRESS PDL.  Hand tweaked bit mapped fonts can always be made
to look better than outline fonts.  Sure, they take more space than
outlines and you can't rotate then 37.851 degrees counterclockwise,
but look at the majority text that is set these days.  I'm not pushing
imPRESS or bitmap fonts, I'm just saying that outline fonts are not
god's gift to typesetting.

>I already use QMS printer, so my real intrest is how different companies
>and handling font technology.
>
>So far it looks like adobe wins hands down and everyone else is scrambling.
>
Well,

You find a printer that speaks real PostScript and

- employs the latest technology Cannon engines
- prints 20 pages per minute
- has multiple paper drawers
- can do duplexing
- can talk over ethernet from VMS and Unix print queues
- can tell the host the number of pages printed in a job

and I'll take serious note.  Good luck.

Ted Ede -- ted@mitre-bedford.arpa -- The MITRE Corporation -- Burlington Road  
|        -- Bedford MA, 01730 -- Mail Stop B015 -- (617) 271-2524 --        |
|                   - this line intentionally left blank -                  |
+---------------------------------------------------------------------------+

curtj@pogo.GPID.TEK.COM (Curt ) (08/04/88)

In article <5122@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
>In article <1766@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>>In article <5090@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes:
>>> So it works with Adobe fonts ?
>>
>>No. 
>This part I understand.
>> Adobe fonts are not part of PostScript.
>This I don't.  Adobe fonts may use secret stuff, but you cant really say
>they are not PostScipt
>> Look at News.
>They coldnt figure it out either, huh ?

In the package you receive with the fonts, It is illegal to break into the
fonts, or if you do, use any knowledge derived form that.  That is part of
the agreement when you open the package.

Its the legal aspects of it that generate the problem.  Not the technical

>Thats what I like about standards.

Standards!!?  They are only standard for Adobe's PostScript.  If you want to 
call that a standard, you better tell Webster.

>I already use QMS printer, so my real intrest is how different companies
>and handling font technology.

Do you mean font scaling technologies?

geof@imagen.UUCP (Geoffrey Cooper) (08/06/88)

> > 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

richard@gryphon.CTS.COM (Richard Sexton) (08/06/88)

In article <1777@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>  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..
>

I can see how 55MB may not be much to somebody buying a high end laser
printer with ethernet and high speed and a hard drive in it, but
I dunno, maybe it's just me, i didnt think the vast majority of laser
printer installations WERE high end ones.

A more cynical view would have it that it was QMS that bought Imagen not
the other way around. 

-- 
                           Bad sunburn. Real bad.
richard@gryphon.CTS.COM                               {backbone}!gryphon!richard

ted@mitre-bedford.ARPA (Edward J. Ede) (08/09/88)

In article <5296@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
>In article <1777@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>>  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..


>I can see how 55MB may not be much to somebody buying a high end laser
                 ^^
>printer with ethernet and high speed and a hard drive in it, but
>I dunno, maybe it's just me, i didnt think the vast majority of laser
>printer installations WERE high end ones.


Open your eyes and your mind before engaging your mouth.

The Imagen fonts require no more or less space than the Adobe fonts,
regardless of where they are stored.  If you buy an inexpensive laser
printer w/o a hard disk that only talks 9600 baud, you can expect to
spend about one minute to download a face.  If you've got ethernet
and/or a hard disk, it'll take less time.

*** Flame On *** 

I think Mr. Cooper is being very fair describing the Imagen product.
I you don't like Imagen, or UltraScript, or the color of the box, DON'T
BUY THE F*CKING PRINTER.  If you want to ask intelligent questions
about Imagen/UltraScript, please do so.  If you're going to get into a
pissing contest (and I'm guessing that you will based on your assinine
comment about font sizes), do it through email.  This sniping is
getting annoying.

*** Flame Off ***

Standard disclaimers apply.

Ted Ede -- ted@mitre-bedford.arpa -- The MITRE Corporation -- Burlington Road  
|        -- Bedford MA, 01730 -- Mail Stop B015 -- (617) 271-2524 --        |
|                   - this line intentionally left blank -                  |
+---------------------------------------------------------------------------+

greid@ondine.COM (Glenn Reid) (08/09/88)

> > > 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

richard@gryphon.CTS.COM (Richard Sexton) (08/09/88)

In article <38253@linus.UUCP> ted@mbunix (Ede) writes:
>In article <5296@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes:
>>In article <1777@imagen.UUCP> geof@imagen.UUCP (Geoffrey Cooper) writes:
>
>Open your eyes and your mind before engaging your mouth.

Oops. I thought he said 55 megabytes. That seemed a little excessive.

Never mind.
>about Imagen/UltraScript, please do so.  If you're going to get into a
>pissing contest (and I'm guessing that you will based on your assinine
>comment about font sizes), do it through email.  This sniping is
>getting annoying.

I'm sorry if you view my using fonts in sizes from 6 to 800 points
as asinine. I'll start doing it by hand with rular and pencil from now on.

 P.S. Here, you dropped this:  *


-- 
                   Who are these ones that would lead us now ?
richard@gryphon.CTS.COM                               {backbone}!gryphon!richard

edwards@bgsuvax.UUCP (Bruce Edwards) (08/09/88)

In article <4145@adobe.COM>, greid@ondine.COM (Glenn Reid) writes:
> 
> > 
> > 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.

I think Courier (an ADOBE font) is in fact a 'stroked font', I don't
know of any other 'stroked fonts' by ADOBE. BTW is there a reason for
this and does Courier by its uniqueness become a 'toothache-of-a-font'
because of it? 

> 
> 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 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.

How much interpreter overhead goes into decryption in comparison to
a non-ABOBE font? I'm not being troublesome...just curious ;-) 

> 
> 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.

Our graphic arts department consists of 9 Mac SE's, an LW+, and a L-300.
Each SE has a 20 meg internal hard disk. We use a relatively large number
of fonts in producing custom labels and price marking products. These fonts
'exist' in three places in my understanding.

1) Bit mapped representations are installed in the SYSTEM
   Question: Does the new FOND type resource allow you to have only
   one point size installed without loss of screen appearance? This
   in contrast to the way we now are set up with several point sizes
   installed for each font?

2) 'Printer' fonts dragged to the SYSTEM folder from the font release
    disks so they can be 'called up' by an application for downloading.

3) Pre-rasterized versions installed on the L-300 harddisk
   Question: Why do we need the printer fonts in each SYSTEM folder if
   they are _there_ on the L-300 harddisk?

   Question: Assuming we do need them in _a_ SYSTEM folder. Could they
   be in a volume say, published on TOPs and when a station needed them
   could they be routed through LocalTalk to that station? i.e. Is
   a 'font server' product available which will allow me to keep all
   my 'printer font' files in one place? As it is now over 3 meg on each
   station harddisk is sucked up by the 'printer font' files. It is
   very annoying and seems redundant in light of LAN capabilities and/or
   the answer to number 3 above. (sorry if this seems a bit muddled, but
   I'm a bit fuzzy on the mechanics of it all). To clarify a point, why
   can't the application interogate the harddisk on the L-300 first and
   say 'Hey, I got it already on the disk, who cares what's in YOUR SYSTEM
   folder.'? All the MAC wants is the 'bit maps' for screen representation
   it's the printer that wants the PS, and its got 'um? Right? I should
   be able to empty everybody's SYSTEM folders of all those redundant files
   (but why do I suspect I'm mistaken...;-) The only reason I can think of
   to keep them around is for the LW+ when we proof to it, but that could
   be on one machine strictly for proofing.

I know this is very long winded but its worth roughly 27 meg of work space
to me.
 
> 
>  Glenn Reid
>  Adobe Systems Incorporated

(Another unrelated item which you might route to the appropriate person.
I understood ADOBE was coming out with an OCR-B. In fact I'm a beta test
site for it. I've written a program which produces bar codes as double-
clickable Illustrator files which we then build labels around. The problem
is I have to use Helvetica for human readable text. According to UPC specs
the font should be OCR-B. Any movement here? )

Thanks for any help.


Disclaimer: I am participating as a guest of Bruce Edwards. My name
            is Ken Jenkins. Bruce is generally amused with my ramblings
            but does not necessarily agree with them.

            'These are only the shadowlands.' C.S. Lewis 
      ----------------------------------------------------------------- 
        Ken Jenkins as guest of edwards@bgsu
        CSNET: edwards@bgsu
      ARPANET: edwards%bgsu@csnet-relay
         UUCP: cbosgd!osu-cis!bgsuvax!edwards 
      -----------------------------------------------------------------