sasaki@HARVARD.HARVARD.EDU (Marty Sasaki) (11/06/85)
This note is in response to the postings about problems with graphics devices and print queues. I haven't looked through the 'fiche to confirm what I am about to say, but I'm pretty sure that these things are true. It used to be (pre version 4.0) that the print symbiont was pretty stupid. The symbiont didn't do much more than copy a file to a device. Things like FORTRAN carriage control information just got sent to the device driver. It was up to the driver to figure out what was going on. If you look at the line printer driver, there is a bunch of code which figures out things like carriage control. The Unified Graphics Package (from SLAC) Versatec driver used funny FORTRAN carriage control values to indicate graphics mode. Enter version 4 of VMS. Symbionts are a lot smarter now. The print symbiont figures out the carriage control and sends records to the drivers after figuring out what needs to be done. The P4 parameter to sys$qio is always 0. This broke all of my graphics. I modified the driver to check if the first two bytes were a magic number. If they were this magic number, then the driver did graphics instead of text. I would then get a little graphics, then the driver would seem to get confused and drop back into text mode and print pages of garbage. The symbiont was chopping records up so that they would fit on a line. It also appeared to be chopping up lines on carriage returns and line feeds. This was a disaster with raster graphics data. I finally set things up so that the graphics data is copied to the Versatec, bypassing the symbiont entirely. I believe that if I was willing to experiment, I could have come up with a proper set of printer characteristics/forms descriptions/magic incantations to get things to work. The right way to do this is to write a special print symbiont that doesn't mess with graphics data. Kellerman and Smith's TeX package as well as the new Unified Graphics package come with a symbiont tailored to do graphics. Marty Sasaki