Squeak needs printing capabilities (A proposed solution)

jim benson jb at speed.net
Fri Apr 10 00:49:11 UTC 1998


Mike Wirth said:

> 3. If we must add something bulky, make it as modular and removable as

> possible.

I like this statement! I think it means that we should have a
configurable Squeak, where we can have bits and pieces that we can add
and subtract from a core functionality group. Has there been a
suggestion to formalize this?

As I recall, the clever thing about the MVC model was the separation of
the model (data) from the appearance of the data on the display. Since a
printer is just another form of display, the printing problem does not
seem to be manageable at the VM level. I like programming in high level
languages, VM support should be something on the order of "write
character to printer" or something clever like that.

With that said, I think that the solutions presented have all had merit.
The line printer idea is useful to print out source code, Postscript is
a nice page description language, and PDF more so. Oh, and HTML has a
wide user acceptance appeal.

This also outlines the dilemma. Each one of these implementations has a
cost associated with it. I would think that having a PrinterDisplay
object would be good fun. I would also like having Squeak talk in
Postscript ( Forth roots showing ). A simple translator is required.
However, a Postscript  translator, PDF translator SHOULD NOT be in the
standard image distribution, but rather available as pluggable add in. I
would vote for the standard image to be the standard image, the basic
root of Smalltalk. Printing is clearly application dependent.

Jim Benson
" Printers kill trees "





More information about the Squeak-dev mailing list