It seems to me that Smalltalk has always been extremely weak when it came to printing, and I was wondering if any thought had been given to improving this in Squeak. At the moment, I believe the entire printing infrastructure is based solely on Form>>primPrintHScale:vScale:landscape: <primitive 232> and nothing else. In these days of cheap, high resolution printers it seems rather odd that all we should get out is screendump quality stuff. Most of the VM implementations don't even do that - the Mac punts, and UNIX simply coughs out an XBM file.
With the advent of Balloon and the primitive TrueType support, it seems at least possible to think about resolution-independent rendering, and defining some sort of abstraction for printing that could work across the majority of platforms.
An approach that might be interesting is to play the same game that Apple's QuickDraw 3D for rendering. It recursively broke complex 3D objects into simpler datatypes, until the specified renderer would accept them. What might work for Squeak printing is something that queried the underlying OS printing architecture for its capabilites and decomposes the print job until it is accepted, or at worst, where it's at now - a Form.
Another possibility is to include various translators for retained internal graphic objects to printing languages such as Postscript, but I think that it's not abstract enough.
=================================================== Duane Maxwell dmaxwell (at) launchpados.com CTO http://www.launchpados.com Launchpad, Inc. (619) 578-8500 x226
Information contained herein is my personal opinion and not necessarily that of Launchpad, Inc. ===================================================
Another posibility for printing would be to port Squeak to a printer platform. They are already supporting Postscript VM's. This seems to be a squeaky-clean way to get a portable imaging model.
-- Mike Klein
mklein@alumni.caltech.edu
squeak-dev@lists.squeakfoundation.org