[comp.sys.mac.programmer] Printing Questions

mkt059@ipl.jpl.nasa.gov (Mike Tschudi (Cartographic Applic.)) (11/26/90)

Keywords: printing
Date: 26 Nov 90 22:10 GMT

> Group: comp.sys.mac.programmer, Item 13162,
> Subject: Printing Questions
> From: leue@galen.crd.ge.com (Bill Leue), General Electric Research &
Development
> 
> 1. I want to be able to print thin hairlines; down to as thin as the
> printing device can support, or at least to some width much thinner than
> 1 screen pixel.  QD only allows you to set the pen to a 1x1 with PenSize(),
> no thinner, unless I am missing something.  Is there a 'standard' way to
> draw thinner lines?  How does MacDraw II do it, for instance?  With
> PICT comments?  I suppose I could generate the PostScript directly for
> PS printers, but that seems to pretty much bypass all of the standard
> print driver structure.
> 
> 2. (Related to #1) I want to be able to locate the vertices of polygons to
> an accuracy better than plus or minus one screen pixel.  That is, I have
> a display list containing many sets of double-precision coordinates.  When
> I render to the screen, I round these coordinates to the nearest integer
> pixel coordinate, load them into an appropriate data structure, and call
> PaintPoly().  I want to do something similar for printing, but make use
> of the (usually finer) pixel grid on the printer so that the round-off
> errors are smaller.  Note that I'm not worrying here about reducing
> the "jaggies" caused by aliasing:  I'm aware that the print driver already
> handles this aspect of line drawing.  Rather, it's the location of the
> endpoints that I care about.  The same questions apply as for #1.


See Inside Mac, vol 5, page 416, to change the resolution of the printing
port. This is great stuff, and our maps look MUCH better using 300 dpi (our
LaserWriter's physical resolution) than they do using 72 dpi. (Your drawing
routine has to handle the varying resolution to maintain WYSIWYG, however.)


Michael Tschudi
Cartographic Applications Group
Jet Propulsion Lab, Pasadena, CA

leue@galen.crd.ge.com (Bill Leue) (11/27/90)

Apologies if these subjects have been covered before.  I am trying to
figure out how to best use the resolution of various printing devices,
both PostScript and non-PostScript.  I have used the high-level printing
commands in other applications, but they don't seem to do what I want
in this case.

In my reading of Chernikoff and others, the high-level printing commands pretty
much work like this: to print the contents of a window, reset the graphics
port to point to the printer, and then just blast away with the same
QD commands that you would use to draw the window.  This works fine for
many applications, but I'm not sure it can handle these requirements:

1. I want to be able to print thin hairlines; down to as thin as the
printing device can support, or at least to some width much thinner than
1 screen pixel.  QD only allows you to set the pen to a 1x1 with PenSize(),
no thinner, unless I am missing something.  Is there a 'standard' way to
draw thinner lines?  How does MacDraw II do it, for instance?  With
PICT comments?  I suppose I could generate the PostScript directly for
PS printers, but that seems to pretty much bypass all of the standard
print driver structure.

2. (Related to #1) I want to be able to locate the vertices of polygons to
an accuracy better than plus or minus one screen pixel.  That is, I have
a display list containing many sets of double-precision coordinates.  When
I render to the screen, I round these coordinates to the nearest integer
pixel coordinate, load them into an appropriate data structure, and call
PaintPoly().  I want to do something similar for printing, but make use
of the (usually finer) pixel grid on the printer so that the round-off
errors are smaller.  Note that I'm not worrying here about reducing
the "jaggies" caused by aliasing:  I'm aware that the print driver already
handles this aspect of line drawing.  Rather, it's the location of the
endpoints that I care about.  The same questions apply as for #1.