note 8
- To: mathgroup at yoda.ncsa.uiuc.edu
- Subject: note 8
- From: shawn
- Date: Tue, 19 Feb 91 08:56:57 -0600
WRI Technical Support (c) Copyright 1989
Technical Note 8
Topic: Graphics formats
Created: July 6, 1989
Written by: Shawn Sheridan
-----------------------------------------------------------
Below is a working copy of some remarks I have on the various
graphics formats that Mathematica supports. At present, it may
not be particularly well organized. But the information should
all be relevant. Note that some explanations must be conceptual
to avoid unnecessary technical detail. The source code was not
tested but should serve its illustrative purpose.
Most modern display devices are raster devices. That is, they
consist of lines of pixels. Each of these pixels is set to a
certain color. To create an image, therefore is to create an
array of colors of pixels. This array is commonly called a
"bitmap". There are several disadvantages to representing images
in this way. First, it is nontrivial to determine which pixels
should be turned on to render say a circle on the screen. Second,
the collection of pixels that are turned on depends on the
resolution of the device. Third, if the image is stored as a
bitmap, the fact that the image contains a circle is lost. For
these reasons and others, several graphics languages were created
for the purpose of describing images in a more convenient way.
These languages at a minimum contain a collection of drawing
primitives in terms of familiar geometric shapes. Some graphics
languages also provide other programming language constructs such
as conditionals, control flow and the ability to write procedures
and functions. Ultimately, however, the drawing primitives in
graphics languages must be consumed and converted into a bitmap in
order to be displayed on a raster device. This is the job of the
language interpreter, at least one of which is provided as a
service of the operating system. There are two common graphics
languages used on Macintosh computer systems: QuickDraw and
PostScript. QuickDraw is the language used to create images on
the Macintosh screen, ImageWriter, and LaserWriterSC printers.
PostScript is the language used to create images on the remainder
of the LaserWriter family of printers. Although PostScript was
originally available only on Apple LaserWriter printers, it is now
used on a large number of devices manufactured by companies other
than Apple.
QuickDraw was originally designed and optimized for rendering
images on a monochrome screen of fixed resolution. PostScript was
designed as a general programming language whose purpose was to
render in a device independent way on high resolution printing
devices. Each is suited to its own purpose and the ongoing
argument as to which is the better language will not be treated
here. Suffice it to say that QuickDraw is fast, and PostScript is
device independent, more general, and provides programming
constructs. However, because there are two languages for
representing images, there must be a way to translate from one
language to the other if an image on the screen is to be printed
on a PostScript printer-more on this later.
Below are the QuickDraw commands to draw a gray-filled, black-
stroked rectangle and a thick diagonal line. These commands are
excerpted from a Pascal program. When this source is compiled,
the QuickDraw commands are converted into calls to subroutines in
the Macintosh ROM that turn the appropriate pixels in memory on or
off. The textual representation of QuickDraw commands never
survive beyond compilation. (Note here that QuickDraw coordinates
increase to the right and downward. SetRect takes its arguments
in left, top, right, bottom order. )
...
SetRect(myRectangle, 20, 40, 100, 70);
FillRect( myRectangle, gray );
FrameRect( myRectangle );
PenSize( 3, 3 );
MoveTo( 0, 0 );
LineTo( 60, 55);
...
In PostScript, the above picture could be described as follows:
...
/myRectangle {
20 0 moveto
100 0 lineto
100 30 lineto
20 30 lineto
closepath } def
0.5 setgray
myRectangle fill
0 setgray
myRectangle stroke
4 setlinewidth
0 70 moveto
60 15 lineto
stroke
...
(Note here that PostScript coordinates increase to the right and
upward by default. The transformation between PostScript
coordinates and QuickDraw coordinates that I have used above is:
Yps = 70 Yqd )
PostScript and QuickDraw use different models for a pen so there
is no direct translation between a QuickDraw pen size and the
PostScript linewidth. I just made a guess that a 3 point by 3
point QuickDraw pen draws on average a line that is 4 points wide.
If you would like to draw this same image in Mathematica, type in
the following expressions:
myRectangle = { {20,0}, {100,0}, {100,30}, {20,30} };
myGraphics = Graphics[
{
{ GrayLevel[0.5], Polygon[myRectangle] }
,
Line[myRectangle],
Thickness[4/100],
Line[{{0,70}, {60, 15}}]
}
];
Show[ myGraphics ]
-----------------------------------------------------------------
The Macintosh uses a data structure called a Picture to store a
sequence of QuickDraw commands. Below is some Pascal source that
creates this Picture in memory.
...
SetRect(myPictureFrame, 0, 0, 100, 70);
myPictureHandle := OpenPicture(myPictureFrame);
SetRect(myRectangle, 20, 40, 100, 70);
FillRect( myRectangle, gray );
FrameRect( myRectangle );
PenSize( 3, 3 );
MoveTo( 0, 0 );
LineTo( 60, 55);
ClosePicture;
...
By calling OpenPicture above, the QuickDraw commands will be
recorded rather than rendered into a bitmap. If later on, the
programmer wished to render the picture into a bitmap, he would
call the DrawPicture procedure:
...
DrawPicture( myPictureHandle, myPictureFrame );
...
This picture exists in memory in a compressed format. Each
QuickDraw command is recorded as an opcode followed by its
numerical arguments. A discussion of this format is beyond the
scope of this note. In fact, Apple for a long time did not even
publish it as Apple considered the format internal to the
operating system. When the sequence of bytes that represents this
recording of QuickDraw commands is stored as a resource in memory
or in a file, it is known as a PICT resource or PICT file. This
is almost always the way that images that are displayed on screen
are stored in memory, and is commonly the way that images are
stored to disk.
PostScript is always simple text. It is not compiled nor
compressed. It is stored on disk as a text file and is
transmitted to the printer as text. This makes it always
readable, always editable, and usually makes an image described in
PostScript quite large. Again, a PostScript file is simply a text
file containing the PostScript text.
------------------------------------------------------------------
Some remarks:
>> Color QuickDraw and PICT2
With the advent of Color QuickDraw, Apple extended the definition
of PICT resources to include color drawing primitives and to allow
for larger PICT resources. This new format is a superset of the
old. It is sometimes called PICT2. Perhaps it's obvious, but
Mathematica uses the PICT2 format.
>> Painting programs
As it happens, one of the available PICT opcodes is for a bitmap
image. An entire image created in a painting program can be
stored as a PICT with one opcode followed by its bitmap data. It
is also possible to combine bitmaps with line, polygon and arc
commands in one PICT.
>> Printing to a LaserWriter
If most images are stored as PICTs, how do they get printed on a
PostScript printer like the LaserWriter? That is the job of the
files LaserWriter and LaserPrep in your system folder. LaserPrep
is a sort of foreign language translation dictionary that contains
definitions of QuickDraw type commands in terms of the PostScript
language. The LaserWriter file will read the PICT opcodes and
transmit them to the printer using the QuickDraw type commands
mentioned above. The LaserPrep dictionary is sent to the printer
the first time someone tries to print a Macintosh document on the
LaserWriter. You may think that since PostScript is a more
general language than QuickDraw that this may be a trivial
dictionary to write. However, since the models that the two
languages use to describe the drawing environment are different,
this is nontrivial indeed. LaserPrep does its best to ensure that
what you see on your QuickDraw screen is what you get on the page
even if you wish that it wouldn't.
>> Embedded PostScript
Since Apple brought PostScript to the marketplace, you would think
that they would provide some means to take advantage of its
features that QuickDraw did not yet provide. Well, they did. One
of the opcodes available in PICT resources is the so called
picture comment. A comment can be any data that a program would
like to embed within the PICT for its own use or for a printer
driver to use. One of the standard picture comments allows the
programmer to embed PostScript text directly in a PICT resource.
The subroutine in ROM that draws pictures into bitmaps will ignore
the comments, yet the LaserWriter printer driver will detect the
PostScript comments and send them along to the LaserWriter and
ignore the associated QuickDraw commands. This mechanism is
convenient because other programs that support pasted in graphics
will automatically support PostScript as well. A word processing
program, for example, need only call the ROM routine DrawPicture
to display the image on the screen, and when it comes time to
print, the printer driver will detect the PostScript comments and
substitute the PostScript version of the picture for the QuickDraw
version. No code whatsoever need exist in the word processor for
dealing with PostScript. Apple wanted this to become the standard
way for programmers to encapsulate PostScript with a QuickDraw
image. Either because software developers didn't understand how
this was supposed to work, or because they were dissatisfied with
the mechanism, another format was invented called Encapsulated
PostScript.
>> Drawing programs
Many clever drawing programs (such as MacDraw and Cricket Draw)
will actually parse through the opcodes of a PICT that has been
pasted into its document. From these opcodes, the program will
construct a list of its own native drawing primitives that you,
the user, can then edit. If you wish to edit individual
characters, line segments or polygons in an image that Mathematica
produces, you should copy the image, convert it to PICT and paste
it into one of these drawing programs. Be warned, however, that
fractional coordinates will be snapped to the nearest integer
coordinates. This results in an image that is not nearly as
smooth when printed on a PostScript printer.
>> So-called PostScript graphics programs
PostScript programs like Illustrator do not contain PostScript
interpreters as you might expect. That is, you cannot create a
text file containing PostScript and open it in Illustrator and
expect Illustrator to render an image on the screen. Instead,
Illustrator uses a model of a drawing environment and collection
of graphics primitives that closely parallels that of PostScript
so that Adobe can use a PostScript text file as its native file
format. However, this file must be in a special format so that
Illustrator can parse it and read back in its list of drawing
primitives. Mathematica, however, does contain a PostScript
interpreter. It is possible to write a PostScript text file and
render it in Mathematica. Unfortunately, Mathematica's own
PostScript interpreter does not yet support all of PostScript's
commands and features. Although Mathematica can render many
PostScript files, it cannot render them all.
>> EPSF
In the Macintosh file system, each file consists of two parts or
forks. The data fork contains data that is typically accessed
sequentially by the file manager. The resource fork contains
packets of data that the resource manager accesses at random. A
typical Macintosh text editor would store the actual text in the
data fork, and such information as the chosen font, tab settings,
or window size and placement on the screen in the resource fork.
Someone had the idea of storing a Macintosh picture as a PICT
resource in the resource fork of a file and the text of a
PostScript version of the same picture in the data fork of that
same file. A file with this format is called an Encapsulated
PostScript File or EPSF. The purpose of such a file was to allow
programs to use the PICT from the resource fork on the screen as a
preview image and to use the PostScript text in the data fork when
the document was sent to a PostScript printer. (Note that there
is no such thing as an EPSF in memory , e.g. on the clipboard. It
only exists in the form of a file on disk. This has caused some
confusion since the EPSF option in Mathematica appears as one of
the Convert Clipboard... options. If you select this option, you
must also click the Save in file... button.)
The EPSF idea proved to be popular and caught on faster than
Apple's embedded PostScript model perhaps because an EPSF is a
text file that can be edited or created by any text editor. But
the programmer has to include special code for dealing with EPSF
files. One other problem with the EPSF format was that it was
specific to the Macintosh file system because it used both the
data and resource forks. Adobe, the authors of PostScript,
realized this problem and proposed their own EPSF format that
placed the preview image as bitmap data directly in the text of
the PostScript. This data takes the form of PostScript comments
at the beginning of a text file containing PostScript. A program
that supports Adobe's new proposed EPSF standard would have to
read the beginning of the PostScript text looking for the preview
image data. It would then have to convert the bitmap data that it
found to a form that could be displayed on screen. Granted, this
is easy, but not as easy as calling DrawPicture on the PICT
resource in the resource fork of the file. Mathematica, and all
Macintosh programs that I know of, use the resource fork to store
it's preview image. This may change because Adobe's idea is more
portable between different systems.
>> Mathematica PostScript
Actually, the PostScript that Mathematica creates does not consist
entirely of standard PostScript. It may contain many non-standard
commands that all Mathematica PostScript interpreters understand,
yet are unknown to standard PostScript devices. In order for
Mathematica PostScript to be rendered on a standard PostScript
device, a prolog must first be sent to the PostScript device that
defines Mathematica's non-standard PostScript in terms of standard
PostScript. In Macintosh Mathematica, this is done automatically
at print time or it may also be done by copying an image to the
clipboard and converting it to an EPSF file. The new EPSF file
will contain the prolog followed by the Mathematica PostScript.
>> Mathematica Graphics
Mathematica uses yet a different language to describe its
graphical images. It uses Mathematica expressions. An expression
with head Graphics, SurfaceGraphics, ContourGraphics,
DensityGraphics, or Graphics3D is the data structure of a
Mathematica graphic. The parts of this expression consists of
lists of graphics primitives such as Line, Point, Thickness, and
RGBColor. The InputForm of one of these expressions will display
the complete list of primitives and options. To create a
Mathematica graphics expression, you may type in the expression by
hand, or use one of the Plot commands that create a graphics
expression. To Display[] a graphics expression is to create a
PostScript description of the expression. To Show[] a graphics
expression is to Display[] it and then interpret the resulting
PostScript to render an image on the screen. When you use one of
the Plot commands, not only do you create a graphics expression as
output, but Plot also Shows the expression on the screen. On the
Macintosh, the Mathematica Graphics[] that results from the Plot[]
is Displayed into PostScript which is sent to the front-end for
interpretation and conversion into PICT so that it can be rendered
on the screen by the Mac ROM. In other words, all three
representations of the image are created and available for use.
----------------------------------------------------------------
Mathematica supports a number of graphics formats and can convert
almost freely between these various formats. An image may be
converted in place in a notebook from the Graph menu or may be
converted on the clipboard following a copy command. Also, an
entire Notebook can be saved as a VideoWorks file and files
containing PICTs (like the scrapbook file) can be opened as a
Notebook. Below is a list of the various graphics formats that
Mathematica supports.
PICT
----
A sequence of QuickDraw commands stored in a compressed format as
a Macintosh resource. This resource may exist in memory (e.g. on
the clipboard) or in the resource fork of a file. If the file has
an empty data fork and a resource fork that is empty except for
one PICT resource, it is called a PICT file. Note that many
different files contain PICTs in their resource fork, including
EPSF and Mathematica Notebooks
Bitmap PICT
-----------
A bitmap PICT is a PICT whose only opcode is for a bitmap. The
bitmap opcode is followed by a potentially large amount of data.
PICT w/ Embedded PostScript
---------------------------
A PICT with two opcodesone for a bitmap and another is a picture
comment containing PostScript text that will be used to render the
image at print time. These PICTs can be extremely large.
PostScript
----------
Mathematica PostScript that can be rendered by any Mathematica
PostScript interpreter. This PostScript must be fixed with a
prolog in order to render it on a standard PostScript device.
InputForm
---------
A Mathematica expression with head Graphics that contains a list
of Mathematica graphics primitives. This expression can be
Displayed or Shown. (see Display[] and Show[] in your text)
Illustrator file
----------------
A PostScript source file in the format that Illustrator uses to
store its documents. This file can be opened directly in
Illustrator and any or all of the primitive elements of the image
can edited or embellished using any of Illustrator's features.
EPSF, (EPSF, TEXT)
------------------
This is a file that contains standard PostScript in the data fork
and a PICT resource in the resource fork. The PICT resource is
used to preview the image on screen or when printed on a non-
PostScript device. The PostScript is used when printing to a
PostScript device. The EPSF some text editors refuse to
open a file of type other than 'TEXT'. Be warned, however, that
if you do open and edit the text in the data fork with a text
editor, the text editor may actually delete the PICT resource that
it finds in the resource forka nasty habit seemingly shared by
most text editors. If you wish to retain the PICT you should edit
a copy of the file and then copy the PICT from the original to the
copy after you are finished editing. You can do this with
ResEdit. Note that the PICT must have ID=256.
PICS
----
The native file format for the animation program VideoWorks is
type PICS. If you save a Notebook in this format, all the cells
that contain PICTs will be added as frames in a VideoWorks
animation.
Which to use when:
------------------
If you wish to edit the image in a painting program, use
Bitmap PICT.
If you wish to paste the image into a word processor that
doesn't support EPSF, use PICT with Embedded PS.
If you wish to edit the image in a drawing program other than
Adobe Illustrator, use PICT.
If you wish to edit the image in Illustrator, convert the
image to an Illustrator file.
If you wish to include the image in page layout or
presentation software use EPSF.
If you wish to dump the image to a PostScript printer, use
EPSF.