Subject: Sun bitmap /special support for dvijep

From: Matthew Self <[email-masked]>
Date: Wed, 12 Oct 88 18:36:32 PDT

Nelson,
  Here are the diffs for my Sun bitmap /special support, which I said
I would mail you some months ago....  The patch is crude, but
effective.  It expects /special commands to be of the form
"/special{bitmap <filename>}.  Really this should also specify the
bitmap format (Sun's), and permit magnification by 2, 3, or 4 if
desired.  Be warned that the patch will compile only on Sun's (it
#includes <rasterfile.h>), so some #ifdefs are probably in order
before wider circulation is appropriate.  Also, this pach may be
applied either before or after the landscape diffs you sent me.

  On a more general note, it would be nice if general bitmap support
were available in all of the drivers.  Printing bitmaps is largely
device independent, being only resolution dependent, and bitmap format
dependent.  I think it would be possible to add bitmap support for
most of the drivers, and support for many different bitmap formats
(X11, X10, Sun bitmap, Sun icon, Sun pointer, ...) in all of them.

  This way a file which includes a bitmap which prints nicely on some
300dpi device ought to print nicely on any 300dpi device.  This is
much better than no portability!  Also, it might be best for the
/special command to indicate the desired resolution (in bpi or
something), so the driver could scale the image to guarantee it comes
out no larger than expected, if possible.  A bitmap which works on a
low resolution printer will come out no less than half as small on a
printer with higher resolution in the worst case.  Of course, bitmaps
prepared for high resolution cannot be printed reasonably on lower
resolution devices (you can't have everything!).

  These are my ideas, but has Tug discussed this idea already?  Are
there any concrete plans?  My main suggestion is that the /special
command include the following information at a minimum:

(1) The word bitmap or some other word distinguishing these commands
    from any non-bitmap commands.
(2) The desired orientation of the bitmap on the page.
(3) The desired resolution of the bitmap.
(4) The bitmap file-spec.
(5) The format of the bitmap file.

  To print landscape bitmaps may require the driver to translate the
bitmap from a row based bitmap format to a column based printer format
(e.g. for HP laserjet+), but the drivers already have to deal with
this on a small scale for most dot-matrix printers....

  So much for bitmaps.  I have a couple other dvi projects on the back
burner which I'd like to ask you about.  I intend to write a /special
command which simply informs the driver of the desired page size and
orientation.  That way, a user can just say lpr foo.dvi and it will
come out right even if he has forgotten that it is a landscape file.
I believe this was also a subject discussed by Tug.  If so, did they
reach a consensus on how this should be done?  I was planning on
simply using /special{landscape} or a /special{legal} at the beginning
of the dvi file, or something like that.  The driver could search for
these before processing the page.  This would be especially nice for
printers which have multiple paper trays and can thus switch without
interupting print service. These may become more common in the future
as laser printers are used more widely (I hope).

  If I haven't touched on enough thorny issues yet, how about color?
We have a Mitsubishi G650 (we had a G500) which is a 300dpi color
printer (the G500 is 240 dpi).  It uses thermal transfer from a
colored sheet, and has cyan, magenta, yellow and black sheets the G500
doesn't have black, but makes by dark purple by using the other
three).  It makes 4 passes to print, but the registration is
excellent.  It can also print directly on transparencies.

  I intend to write a driver for it for black and white only in the
next week or so (it should be easy since it just wants a big bitmap),
but soon I hope to write a color driver for it.  My plan is to modify
SliTeX to generate only one dvi file, bit to include /special commands
to select one of the 6 colors or black.  This will require rather
extensive modification of teh driver software, since I will need to
keep track of four bitmaps, and write characters into one or more of
them.  Then the four bitmaps will be dumped to the printer much like
usual.  I would appreciate any advice on how to reorganize the driver
software to incorporate these changes.  The result should be very
nice.  You will be able to run slitex and generate color
transparencies with no further effort.

  Is this another issue Tug has discussed?  Again, if a plan was made,
I would like to conform.  That's all of my projects, so that's the end
of the hard questions.  Thanks for any help/advice you can offer....

			Matthew Self
		  NASA Ames Research Center
		   [email-masked]