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
|