Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!sdcrdcf!trwrb!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: comp.sys.amiga
Subject: Re: S - L - O - W  Printer Device
Message-ID: <1335@cadovax.UUCP>
Date: Tue, 20-Jan-87 18:09:58 EST
Article-I.D.: cadovax.1335
Posted: Tue Jan 20 18:09:58 1987
Date-Received: Thu, 22-Jan-87 00:29:05 EST
References: <1321@cadovax.UUCP> <1247@cbmvax.cbmvax.cbm.UUCP>
Reply-To: keithd@cadovax.UUCP (Keith Doyle)
Organization: Contel Business Systems, Torrance, CA
Lines: 85

In article <1247@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
>The printer.device does not re-sample the image.
>And you can get no scaling just by making the right call to
>the DumpRPort function.
>All you have to do is either write a screen dump program, or modify
>one of the ones on the fish disk.

Screen dump programs work ok, but that dosen't help DPaint to print
any better (or NotePad, or DeluxePrint, etc.)

Ok, I think I am finally beginning to put the pieces together as to what
is happening:

	1) The application program (as in DPaint) does any required re-scaling
           of the image and passes it to the printer.device

        2) The printer.device will:
             a) check preferences for driver name and related printer params
             b) do the dithering and/or b&w thresholding based on preferences
             c) opens serial or parallel device based on preferences
             d) pass the output to the driver

        3) The driver will:
             a) initialize printer
             b) do line buffering based on pixel by pixel info from the
                printer.device
             c) translate Amiga printer controls to printer dependent
                controls
             d) send the output to the printer

First of all, is this correct?  Are there any important pieces missing?
How do the preferences margin widths etc. figure into the equations?

Second, I have a couple of friends who want to do things with the system
in such a way as to affect ALL Amiga applications that use the printer.
In other words, I don't want to use an outboard program (like ScreenDump)
that gets the job done by bypassing the usual channels. (1-3 above).

One, is we would like to play with alternate dithering algorithms. 
And two, is we would like to produce a Postscript 'driver' if you will,
that makes use of PostScript ability to do dithering at higher resolution
in the printer.  In addition, to find a way to make use of PostScripts 
internal fonts in a useful manner.  (Like produce a 'NotePad' that tells
the printer.device that it's using 'ruby 12' for this font, and have that
translate to an equiavlent PostScript font.

It would seem the only way to do this kind of stuff is to produce a custom
'printer.device'.  Remember, that I want to get the job done WITHOUT
bypassing usual channels, because I want these features to work with 
off the shelf applications that I do not have control over.

Is the printer.device written in 'C'?  If so, is there any chance that
Commodore might make the source available?  Trying to completely re-write
the printer.device by starting from the generic device handler code that
has been floating around looks like a much bigger task.  I'd really just
hack what we've got rather than re-invent the wheel.

Though I still think there are two problems with the existing application-
to-printer chain.  Graphics print speed (whether or not ScreenDump is used or
something else, specifics of which will be forthcoming after we do a few more
tests), and print quality, though I've seen that DPaint II seems to provide
a more 1 to 1 print capability which allows much better output that I was
able to get with DPaint I.  This implies that it was primarily DPaint I's
problem with printing textual material and not the device or driver.

I'm thinking about posting a uuencoded version of my 'test pattern' file
that I use to check this stuff out, so any of the rest of you who are
interested in the kind of problems I'm referring to here can see what I'm
talking about.  It's a lo-res IFF DPaint file that has a worst-case
pattern that I use for testing and adjusting preferences for best-I-can-get
printer output.  Though the printer I'm using has a 640 dot width, which
ought to translate 2 for 1 from a lo-res picture file, unless I set my
preferences margins to 1-84 or greater, DPaint will try to scrunch the file
a few pixels horizontally.  This seems pretty odd, I'd expect to be able
to set margins to 1-80 (or even 1-81) to get the right translation, but
it has to be somewhat larger than that.  And then, I can set margins to
something rediculous like 1-120 and I still get the same image as if they
were set to 1-84.  And of course, DPaint I will still scrunch the picture
vertically anyway trying to force the aspect ratio to reflect the screen.
Fortunately, DPaint II allows you to override the screen aspect ratio in
the interest of quality output (especially with text).

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
#  cadovax!keithd@ucla-locus.arpa