
			Graphics formats
						Shawn Sheridan
						shawn@dragonfly.wri.com

WRI Technical Support (c) Copyright 1989
July 6, 1989



  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.
  
  
  >From shawn@dragonfly.wri.com Tue Feb 19 09:41:35 1991
  Received: from dragonfly.wri.com by yoda.ncsa.uiuc.edu with SMTP id AA14277
    (5.64+/IDA-1.3.4 for stevec); Tue, 19 Feb 91 09:41:32 -0600
  Received: from wri.wri.com by dragonfly.wri.com with SMTP id AA11280
    (5.65+/IDA-1.3.4 for mathgroup@yoda.ncsa.uiuc.edu); Tue, 19 Feb 91 09:42:07 -0600
  Return-Path: <shawn>
  Date: Tue, 19 Feb 91 09:42:05 -0600
  From: shawn@dragonfly.wri.com
  Message-Id: <9102191542.AA07956@wri.wri.com>
  To: mathgroup@yoda.ncsa.uiuc.edu
  Status: RO
  
  I would like to make a few remarks.
  
    * The notes that I sent out are quite old, I hope they are still useful.
  
    * There is some confusion, I think, between encapsulated PS files and
  conforming PS files.  The EPSF format was invented on the Mac.  It simply
  placed PS source in the data fork, and a PICT preview image in the
  resource fork of the file.  Since then, EPSF has come to mean attaching
  a preview image to PS source so that an enclosing program can show an
  approximation of the image on screen easily without interpreting the PS.
  Adobe has suggested a standard for including a preview image as PS 
  comments near the beginning of the file.
  However, EPSF has become to more loosely mean "PostScript".  That is,
  when an enclosing programs like say page layout programs say that they
  support EPSF, they mean that you can designate a box on the page in
  which some PS gets rendered.  If a preview image is available in the file
  you will see on your screen an approximation of printed image.  If the
  preview image is missing you get an empty or gray box, but you still get
  a nice image on paper. 
  
    * The perhaps more important issue is conforming PS.  A PS file is 
  said to be conforming if it makes suitable declarations to an enclosing
  program about its contents so that the enclosing program can do something
  reasonable without interpreting the PS itself.  (The declarations are made
  as PS comments, which of course a PS interpreter ignores.) These comments
  allow the creator of the PostScript to include such information as the
  bounding box inside which ink will be laid down (which presumably the
  creating program or person knows); when the PS for the current page ends,
  and a new page begins, and other useful things.  This allows the enclosing
  program to say scale and translate the coordinate system before sending
  the included PS off to the printer; or print pages in reverse order; or
  print thumbnail pages, &c.
  
  * What psfix emits is minimally *conforming*  postscript, not encapsulated
  PostScript.  After all, psfix is just a shell script.  To include a preview
  image, it would have to render the postscript and grab the resulting
  bitmap -- a tough job for a shell script.  (Although it could ask for help
  from sunps, or x11ps, &c.--it doesn't.)  What it does is include a *few*
  conforming comments for enclosing programs and a prolog containing
  definitions that make the PS from Display[] understandable by a 
  standard PS interpreter.  The bounding box comment is all that a
  page layout program needs; preview comments would be nice a nice extra,
  but are not provided by psfix.
  
  * The enclosing program is supposed to redefine showpage in the scope of
  the included PS to do nothing or something reasonable.  Whether a file is
  conforming PS or encapsulated PS has nothing to do with showpage.
  
  --Shawn Sheridan
