Re: Printing MAC bitmaps on GS

[nathan@cco.caltech.edu (Nathan Mates)]

In article <3h5ohp$ct7@clyde.ics.uci.edu>,
Leif Strand <lstrand@ics.uci.edu> wrote:
>In article <3h34gd$6u3@gap.cco.caltech.edu>,
>Nathan Mates <nathan@cco.caltech.edu> wrote:

>>   If you were to print it at this point, the Mac still has the 300dpi 
>>info to print it nicely, but the GS has 1/16 the data (1/4 in both
>>horizontal and vertical) to work with. 

>Bitmaps on the Mac are always 72 dpi -- "internally", on screen, and
>when printed.  We are talking about MacPaint, right?  Who ever heard
>of 300 dpi MacPaint files?  Ask Bill Atkinson -- his program ran on
>the original 128K Mac; somehow I doubt that there was enough free
>memory available to store a full- page, 300 dpi bitmap "internally" --
>but then he _was_ a wizard; I could be wrong.

   (Hint: 70 columns, not 79. It makes quoting for followups so much
easier)

   I have read brochures for Mac clip art collections, and they say
that they are pretty much 300dpi. Converted to 72dpi for the screen,
but they are defined at 4x that (288dpi), which is why most older Mac
drivers had the option of printing at 288dpi for speed, rather than
stretching 288->300. 

   Original MacPaint probably can't handle anything more than a raw
screen image, true. But, I hate to tell you this: there are programs
for the mac newer than that. Lots of programs have come out since
then.


>In general no paint program stores bitmap files at 300 dpi, and further, 300
>dpi bitmaps are never chugged over an AppleTalk line to a LaserWriter. 

   Heck yes they do and are. Superpaint 3.x (and probably earlier
versions) naturally does stuff at 300 dpi. And things are sent at 300
dpi to a Laserwriter: pictures and non-native fonts. (Fonts that the
LW has in ROM can be sent as ascii, but everything else is downloaded
as a 300dpi bitmap). 

   Ever print a 300dpi postscript file to any printer? It takes a
while.  That's because you're shoving 17x the info at the printer, and
the printer has to deal with 17x the info.

   Also, if you take a 72dpi source on a Mac program, and cut its
size in half twice, and the extra pixels are not thrown away, it'll
get sent to the LW at 288dpi. Scaling it by 24% in X and Y will up it
to 300dpi.



> The
>high resolution of a laser printer is internal to the printer and is produced
>in response to geometric PostScript commands issued from a shape-oriented
>"draw" program such as MacDraw.  But bitmaps from a "paint" program such as
>MacPaint are still printed at 72 dpi, even on laser printer.

   If the Mac host program can only handle 72dpi, it prints to the
printer driver at 72 dpi. If it's got a 300dpi printout, it feeds
the driver a 300dpi image, which is then sent to the LW at that
resolution. If the driver gets a 72 dpi image, then either it or
the LW (not sure which) converts it to 300dpi before printing.

   LWs cannot do 72dpi naturally; they operate at 300dpi internally.
72dpi stuff is upped to 300dpi before printing, but if you have 300dpi
source material (fonts, pictures, etc), who the heck would be so stupid
as to convert it to 72dpi then back again at the printer?




>The reason why the print resolution of the GS is so low is because the screen
>resolution is so low, and any WYSIWYG printout has to display a chunkyness
>that resembles the screen somewhat.

   The GS's screen resolution is so low that's the problem? Sorry,
wrong again. Standard Mac/Windoze is 640x480, GS is 640x200. If screen
resolution was the fault, then the pictures would never be chunky in
the horizontal dimension, simply vertically. But, this isn't the
case. Any printout you do from a paint program (even with 'vertical
condense' off) will be chunky in both directions. This is because
the source is 72dpi, the computer's screen, but our eyes want more
on a printout.


   "Any WYSIWYG has to display a chunkiness that resembles the
screen"? Where the heck did you get that load from? The size of things
and relative positions should be the same, yes, but the resolution should
not change this. 

   Case in point: if you have a font 2x or 4x larger, the printout is
much smoother. Why? Because what's on the screen is chunky due to the
low _screen_ resolution. But, the printer is not connected to the
screen. It is connected to the computer through a driver. The driver
figures out that the printer can do things at 4x the resolution, and so
it sends a larger font, and tells it to draw 4x as many dots in the same
area on the page.

   Same thing with other computers. Ever view the same page of text on
a 9" Toaster Mac monitor, and then on a 21" monitor? The 21" monitor
can do a smoother job at the font, but the printout will look the same.



>  Also a printer such as the ImageWriter II
>can only print 8 colors so you need larger pixels to simulate all the colors/
>halftones possible on the screen, using dithering.

   No, you print at 144dpi (what the IWII can do, double screen res),
and dither within that. But, printing to a LW has absolutely nothing
to do with the Imagewriter; the drivers determine what is sent and
how it's printed. The Laserwriter driver does not use 'larger pixels'
of any sort, it uses grayscales, and does not expand the printed area.

   This can be proven by any program that does true graphical objects
on the GS. (AWGS sure doesn't). If you tell the printer driver that
you have a line on the page from point A to point B (rather than a
bunch of 72dpi pixels), the printer driver will do the job of drawing
the line at whatever dpi the printer does, making it far smoother than
the screen display.



>  The trick to printing a MacPaint file nicely is getting a conversion
>of it that is stretched vertically just like fonts are on-screen, and then
>print it in condensed mode -- or, alternatively, getting a gigantic 320 mode
>conversion that isn't stretched and printing it at 50% reduction (but not
>condensed).

   You've finally gotten back to what I said in the first place: it's
not the GS's screen which is the problem, it's the source material.
Get a big source, and shrink it while you print it. Get out of this
'Macpaint' and 1984 Mac technology; computers have grown up since
then.

Nathan Mates
-- 
* Nathan Mates   http://www.ugcs.caltech.edu/~nathan/              <*>
* Ftp humor archiver: ftp to ftp.cco.caltech.edu, look in pub/humor *
* "Always listen to experts. They'll tell what can't be done, and   *
*  why. Then do it."  -- Robert A. Heinlein, Lazarus Long           *