<The following is somewhat dated because I started writing it yesterday
(before being interrupted).  It's amazing how many interesting comments
come across the Squeak list in a short period of time:-)  BTW, add Ted's
suggestion of HTML to mine below.>

Patrick Logan said:
>Maybe there should be two efforts:
>
>(1) Sending text to a line printer.
>
>(2) Rendering postscript.
Others have talked about GhostScript (as an embedded PostScript rendering
engine, perhaps).

I think we need to be very careful about adding too much bulk to the Squeak
environment.  I want to be able to use it for handheld devices, for
example, and my priorities are:
1. Keep the minimum runtime size as small as possible.
2. Keep the amount of C code necessary to implement and/or port the system
as small as possible.
3. If we must add something bulky, make it as modular and removable as
possible.
4. Enhance our leverage to take advantage of existing solutions.

A. Considering these priorities, how about the following solution (in
analogy with QuickDraw and PS on the Mac):
  1. Add methods to the Morphic objects to render themselves on a
PostScript port (instead of the display).
  2. Add the minimum necessary to the platform-specific code to package up
this PostScript stream and direct it to:
    a. a file, or
    b. a printer, or
    c. a separate rendering application (e.g., GhostScript runnning as a
separate process).

I can't imagine why you would really want A.2.c. except if there were
differences in rendering fidelity or features between Morphic=>screen or
PostScript=>screen  (all the old arguments about QuickDraw to PostScript
conversion and the merits of Display PostScript come to mind).  And since
we control the Morphic code, we should be able to keep rendering to the
screen and rendering to a print stream reasonably close together.

B. If what you want is the ability to generate high visual quality,
navigable, on-line documents from Squeak, then I have an even better
suggestion for you:  In the above proposal, substitute PDF for PS:
  1. Add methods to the Morphic objects to render themselves on a PDF port
(instead of the display).
  2. Add the minimum necessary to the platform-specific code to package up
this PDF stream and direct it to:
    a. a PDF file (which, in fact, is a navigable, object-oriented,
read-only database -- See the PDF book, updated edition), or
    b. a printer, or
    c. an embedded rendering engine, consisting of the existing and
available PDF plugin for Netscape Navigator, plus the necessary portions of
the Navigator plugin interface (taken from the now-available Navigator
source code :-).

This approach has all kinds of interesting characteristics:
1. Online viewers and the ability to print PDF files is readily available.
2. PDF files are resolution independent, and font support is excellent.
3. Treating PDF files as OODBs, in which we can add arbitrary properties to
objects, e.g., Smalltalk code, means that we can generate "active
documents" with hyperlinks, active computations, etc.  Reminds me some of
the "notebooks" in Mathematica.

Mike Wirth
IBM Almaden Research Center