Anyone ever used PrintJobPlugin?

Andreas Raab andreas.raab at gmx.de
Thu Aug 7 19:09:40 UTC 2003


Hi John,

> 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.

Right, that's why I am asking, and interested in finding out if anyone ever
made good use of it.

> > a) ioPrintPreProcessing and ioPrintGetFirst/LastPageNumber
> 
> 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. 

All right, got that (same on Windows).

> 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. 

Got that too (again, the same on Windows).

> 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.

Nope, actually it's the same over here. There's one more standard setting in
Windows print setup dialogs which can might make sense - it's printing of
the "current selection" in some app. It might be worthwhile to support this
if possible as the "current selection" might be interpreted as the object
currently having the halo or somesuch.

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

Same over here.

> > b) ioPagePostscript and ioPageForm
>
> Old macintosh laserwriter drivers would allow injection of 
> postscript into a page,

Windows docs claim that PS printers can support the same which led me to
asking this question. I suspect that we should a) have a way of figuring out
if a printer is Postscript capable and b) restrict it by definition to EPS
(e.g., if you have a showpage in there it's undefined what happens).
However, I need to try this first, before I can make any assertions about
it.

> 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.

Okay, so I take this as a "nobody has ever done it yet", correct? ;-)

> > c) ioPageForm coordinates
> 
> 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.

That really doesn't sound overly useful to me. I'd muchly prefer the
ioFormPrint interface which specifies the dpi requested instead of a scale
without any reference frame (e.g., what happens if you print it on a 300dpi
vs. 1200dpi printer?). The size of the form is then defined implicitly and
for scaling a form up to a page size you should really know about the page
size of the printer (see below). So what I'd propose is to pass along the
dpi (just like in ioFormPrint) and interpret the offset in the same
resolution. E.g., for 100dpi an offset of 100 means 1 inch. This should work
for all but the most obscure cases ;-)

> Technically on the mac we consider 1 inch to be 72 pixels,
> but on windows isn't that 96 pixels?

It actually depends. You have to ask the device (display, printer) what its
device resolution is.

> If you draw to a 360x720 dpi inkjet, does that mean you
> need to scale the form to 360/720 before printing?

This is handled by mapping modes which use physical units instead of device
units (typical mapping modes are 1/100 inch or 1/100 mm).

> > d) Page sizes
> 
> 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?

Well, all we need is to figure out what kind of paper to use which is
typically part of both, the print setup and the print dialog. Shouldn't be
too hard to pass that along (I know that on Windows it's utterly trivial).

> 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.

I would _really_ want to have this. If nothing else, you could report a
pseudo page size up to the ST side and then use this as a basis for any
further operations.

Cheers,
  - Andreas



More information about the Squeak-dev mailing list