Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!wagner
From: wagner@utgpu.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: printer.device from HELL
Message-ID: <1987Feb10.050928.24803@gpu.utcs.toronto.edu>
Date: Tue, 10-Feb-87 05:09:28 EST
Article-I.D.: gpu.1987Feb10.050928.24803
Posted: Tue Feb 10 05:09:28 1987
Date-Received: Tue, 10-Feb-87 18:35:21 EST
References: <1377@cadovax.UUCP> <1342@cbmvax.cbmvax.cbm.UUCP> <1384@cadovax.UUCP>
Reply-To: wagner@gpu.utcs.UUCP (Michael Wagner)
Organization: University of Toronto Computing Services
Lines: 165
Checksum: 00517

In article <1384@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
>
>The printer.device
>itself is VERY flexible.  It seems that Commodore expected the applications
>writers to RTFM, understand fully what the role of the printer.device is, and
>make sure they provide user access to the flexibility found there.

This point was made some time ago in this discussion.  The printer.device
is under-documented for the level of sophistication that is in it.
It is only now somewhat documented in the Rom Kernel Manuals, and it seems
that most developers didn't have/didn't read the RKMs beyond the stupid
overly simplistic examples.

>Unfortunately the only applications writer I have been able to identify who
>has actually done that is Dan Silva, author of DPaint II.  

And he sure didn't in DPaint I!

>It would seem
>that most of them simply copied the DumpRPort() sample routine out of the RKM
>without taking the time to understand what 'printing on the Amiga' is all
>about (or was intended to be all about).  

Actually, the part that seems the most unfortunate to me is that many 
unsophisticated users will see the lousy results that the combination of
Amiga+expensive.printer+stupid.developer produces and go get a mac.
Remember, Andy, while you and Keith are arguing over whether it is the
printer, the driver, the .device, the application or the OS that blew 
a particular screen dump, the fact remains that the end user neither knows
nor cares...he didn't get the results he can now get from decent packages
on other machines.  Most auto buyers just notice that the car is too slow or
too awkward...they don't wonder if the fault is in the engine division or
in the transmission division of the auto company.  And a transmission that
can accept many different engines and provides flexibility for the future
isn't a feature for any but the most sophisticated buyer.  Most buyers are
just buying a package.  It either all works together or it doesn't. 

I agree that the problem is (mostly) with the applications not using the
power of the printer.device properly.  But I feel that C-A has not done
enough to keep the developers informed in this area.  You guys had style
hints on using Intuition in the manuals.  How about a 'how to use the
printer.device to get the best results' section?

I do think, however, that there is no great sin in allowing the user 
access to features.  You warn him that his picture may look different if
he plays with these sliders, but you let him do it.  ITS HIS DATA, DAMN IT!
I designed and built (from, basically, off-the-shelf parts) 
a mainframe system where one of the philosophies was
borrowed from micro land...don't get in the way of a user with a job to get
done.  We relaxed quite a number of stupid restrictions that the original
system had.  Some new features didn't seem like they would be a lot of use.
Some of them we put warnings at the entrance to.  But we let the user do it.

I'd like to see the printer driver allow touch-up of the colour map before
the output went to the printer.

I complained months ago that the colour dithering was wrong on my OKIMATE-20.
I've gone to the trouble, in the mean time, to look up references and buy
a text on the subject.  I now am starting to understand why this is a complex
problem.  Given that the text gives 4 competing algorithms for doing this,
and claims that none of them work properly for all pictures, how can you
claim that an algorithm with no parameterization is doing it right?

Actually, I'm glad that Keith was more persistent than I was.  Perhaps
it's because he's actually trying to develop something, while I'm only
here to play.  

I'm glad Andy suggested that the printer.device could be front-ended.
I was thinking about doing this, but lacked the knowledge to determine,
a priori, that it is technically feasable.  I've written some ugly
application-level code to get the results I wanted out of my dot-matrix
printer.  I was thinking of posting it, and letting other, more 
systems-oriented heads insert it in the right places in the driver code.

Perhaps this would be a good place to talk about enhancements I would like
to see for the printer support on the amiga.

1) Printer spooling in the printer.device.  User selectable choice of
   spool file naming (so it could go in ram or hard-disk, if those
   were available).  Tunable buffer-size options so that seeking back
   and forth to the spool files could be minimized.
2) Support for port expansion devices on both the serial and parallel ports.
   A preferences item (submenu) would let you set up the strings used
   to select the various ports of your port expansion box.  Support at the
   DOS level would be multiple, virtual printer devices.  In fact, other
   devices hung off the parallel and serial ports could also be represented
   as virtual hardware, I suppose.  
3) It should be possible to output to the printer using the same 
   (type of) calls used to send graphics output to the screen.  In fact,
   I do (almost) this in one application.  You open a virtual printer
   page, render into it, and then print it.  There are problems if a
   complete page takes more memory than you have (or can BLIT in), but
   they can be solved using multi-pass algorithms and the support already
   in LAYERS for superbitmaps and redrawing damaged (unrendered) segments.
4) The application should be able to determine various device-dependent 
   information (like vertical and horizontal resolution, colours available,
   and so forth....most of the stuff in the printer.tag would be a good
   start) in a structured way...i.e., a call to the printer.device.
5) The printer.device should understand dot aspect ratios of the printers,
   and the various special things that can be done with specialized 
   printer drivers.  This should include such things as overstriking on
   impact printers, and the ability to position dots close enough together
   to overlap.  Half-tone algorithms should use overstrike when available.
6) The printer drivers should (perhaps optionally, perhaps tied to the
   draft/final flag) use higher resolution modes when available.  For
   instance, the Epson driver should use the 216DPI resolution.  It's
   REAL slow compared to the supplied version, but the results look 
   MUCH better (and my driver is still nothing like the 30 minutes Keith
   was talking about).
7) The printer drivers should all compress out large sections of white
   space.  This could be done with a supplied piece of code in a library,
   to cut down on the amount of reinventing of graphics wheels that needs
   to be done.  This can be expected to be a win, because every byte sent
   is an interrupt.
8) The printer drivers should probably allocate their buffer storage in
   CHIP ram, and use the blitter to clear it after each use.  If you have
   expansion memory, you surely can afford the CHIP ram and would like the
   speedup.  And if you don't have expansion memory, you haven't anything
   except CHIP ram, so you're already doing it.
9) If the supplied code in the RKM is production, the printer drivers should
   probably be corrected to not set every bit twice using two slightly
   different codings of the same algorithm.
10) Perhaps some performance analysis of the printer.device/printer driver
    interface is called for.  I suspect that one or two more calls to handle
    cases where significant amounts of redundant information is being sent
    might speed things up a fair bit.  For instance, a call which says to 
    set positions x=10 to x=900 in the same scan line all to one colour
    would save 890 function calls, with all the overhead involved.
    Instead, a tight loop of a few instructions per bit.

Hmmm...I had some more ideas, but I can't seem to recall them at present.
Well, after all, it is 4 in the morning.  And this article is getting long
enough already.  More later, if I remember any more.

Oh, actually, a few comments for people trying to write printer drivers
from the RKMs.  They forgot to tell you a few things.  You must compile
the code with stack checking turned off.  Neither the Fish CC nor the 
Lattice LC front-ends let you specify this.  You have to call the phases
yourself.  You don't really need c.o (or [AL]startup.obj, as they used to
be called).  You do have to supply a few funny things that I stole from c.a
just to get it to link.  I don't remember them off the top of my head.
And I couldn't find any good reason to keep data.c separate from dospecial.c,
so I put them together.  I found that the initialization code (which was all
I really needed dospecial for, anyways) merely chose to send strings that 
were already defined in data.c; it made sense to combine them for readability
and reduction in data size.  Dospecial seems to be able to perform all sorts
of magic with setting the return code... never figured out what they all
meant.  Some documentation in this area would be really handy.  The render.c
entry codes in the code are numbered differently from the text description,
and master initialization is not described in the text.  The only example that
uses master initialization uses it to clobber values in printertag.asm.
This practice begs the question of when those values have meaning, and who
is allowed to look at them, and when they have to be kept consistent, and
so on.  Need more doc here too.  It also would have been handy to have, 
somewhere, a list of what the preference settings related to printing are
supposed to mean, and who is supposed to honour them.  For example, the
margins settings seem to be honoured by some applications and not others.
Seems like the drivers don't implement that feature.  Which means that
a plain, ordinary AmigaDOS application using the PRT: device won't honour
them (I sent a paper through PROFF three times before I figured out that 
the knobs weren't connected to anything).  I could go on and on (I already
have! :-) ).  Enough for one night.


Michael