Anyone ever used PrintJobPlugin?

John M McIntosh johnmci at smalltalkconsulting.com
Thu Aug 7 18:35:26 UTC 2003


Hey it says right in the PrintJob class comments:
"A simple print interface by johnmci at smalltalkconsulting.com
Originally written for macintosh carbon applications."

Now the fact it's written originally for macintosh carbon applications  
means it has a bit of platform
specific attributes, also it's "simple"  I think you are the first  
person to attempt to use it on any other
platform so now we'll see how cross platform it can be.

On Thursday, August 7, 2003, at 07:17  AM, Andreas Raab wrote:

> Hi,
>
> I was looking at implementing PrintJobPlugin but the lack of any  
> comments
> whatsoever leaves me really puzzled about what is actually expected by  
> the
> plugin. A number of questions:
>
> a) ioPrintPreProcessing and ioPrintGetFirst/LastPageNumber
> Is it expected that ioPrintGetFirst/LastPageNumber answer the number of
> pages which a user has selected? Does this imply that  
> ioPrintPreProcessing
> has to provide a UI for the user to select the range of pages?

First in the primitivePrintSetup we call the OS page setup logic which  
on the macintosh allows you to pick the  paper size or type of paper,  
the printer and the orientation and scaling which is done by the OS  
printing subsystem. On the macintosh you get this when you pick "page  
setup" from the application menu in all macintosh applications.  Really  
the primitivePrintSetup is the call that setups things for printing,  
you'll note it returns sessionBits which is the handle to any  
interesting control structure you had to allocate and now drag around  
with you. Also note it gets stuffed in a weak registery so closure on a  
GC event can occur if the client forgets to do that. Technically  
nothing prevents you from having a printjob instance for landscape,  
then one for lables, active at the same time, mind I've never tried  
this.

In the ioPrintPreProcessing the macintosh printing architecture  
presents the user with the os print dialog with allows the user to pick  
a printer (again) then change the attributes of the printer. OS-x lets  
me save the print request as a PDF etc at this point... On the  
macintosh you get this dialog when you pick "print" from the  
application menu in all macintosh applications.  Now one of the items  
of interest here is how many pages to print because we need to tell the  
dialog how many pages the document has, then in return we expect  
somehow to get back the user's choice of start and end page, IE  
primitivePrintGetFirstPageNumber. That is a implementation specific  
issue for the macintosh.

The macintosh provides these dialogs as part of the OS. Other platforms  
need to somehow collect that information for the primitive.

>
> b) ioPagePostscript and ioPageForm
> The only available comment claims that
> 	"you invoke setForm: or setPostscript: to image a form
> 	 or postscript as many times as needed, then as mentioned
> 	 pagePostProcessing to close the page".
> Does this mean a mix of the PS and Form printing should be allowed? Is  
> it
> valid if PS spans multiple pages? Is it valid to embed a 'showpage' in  
> the
> PS? Shouldn't this rather be EPS?

Old macintosh laserwriter drivers would allow injection of postscript  
into a page, this doesn't seem to work but was left in in case someone  
wanted to really make it work. I left the prims in because I know  
Squeak can generate EPS, but then it's an issue in the plugin to deal  
with that.

>
> Contrary to the above comment, the actual implementation of PrintJob  
> looks
> as if there can only be either a single form or ps be passed to the
> PrintJob. Is this intentional, or merely due to being a sample
> implementation?

See PrintJob:>>startJob which iterates over the collection of Forms  
invoking
pagePreProcessing
setForm:
pagePostProcessing

terminating with
primPrintPostProcessing:

So if you have 10 forms you loop 10 times creating 10 pages. I don't  
think there is anything
preventing you from calling setForm: multiple times within a  
pagePreProcessing/pagePostProcessing. The
Forms just get copied onto the printing architecture at the
primPageSetForm: aSessionHandle bits: aBitMap height: h width: w depth:  
d scaleH: sh scaleW: sw offsetH: oh offsetW: ow
call. The pagePreProcessing and pagePostProcessing set the start/end of  
the page drawing, so mulitple calls to image are viable.

>
> c) ioPageForm coordinates
> The function specifies a "scale" and some "offset" but it doesn't  
> specify
> any resolution for those. How are those values assumed to be  
> interpreted?
> How would one (for example) print a form which starts 3 inches from the
> top-left of the page and is 2x2 inches wide?

scale is 0-1.0  (0 to 100%)
Other values are dependent on what the primitive things they should be,  
if inches is a windows thing, then
you'll need to covert from pixels width of a form to inches I guess. On  
the macintosh for historical reasons pixels on the screen are 1/72 and  
1/72 on paper.  So if the form on the screen is 2x2 inches or 144x144  
pixels then that is want appears on the page (in theory), so those  
integer values are 1/72 (or should we say screen resolution?) It's very  
possible you need a helper here to translate between Form resolutions  
and printing resolutions. Technically on the mac we consider  1 inch to  
be 72 pixels, but on windows isn't that 96 pixels? If you draw to a  
360x720 dpi inkjet, does that mean you need to scale the form to  
360/720 before printing?

>
> d) Page sizes
> The PrintJob plugin does not specify what page size is being used for a
> print job. How is any client supposed to do printing without knowing  
> what
> the size of the paper is going to be?

This is done in the macintosh print setup, page setup dialogs. Another  
prim or two might be need to support an OS that require you to manage  
your own dialogs and then pass that information in? Right now the  
controls are minimal from the programming side, getting/setting page  
sizes, resolutions, ink type, vendor paper etc,  is way more work and  
never a cross-platform friendly solution, and really I got to avoid  
having to worry about doing that.

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===



More information about the Squeak-dev mailing list