Path: utzoo!utgpu!watmath!att!ucbvax!agate!shelby!polya!rokicki From: rokicki@polya.Stanford.EDU (Tomas G. Rokicki) Newsgroups: comp.text Subject: Re: HP DeskJet Plus DVI driver? Message-ID: <11222@polya.Stanford.EDU> Date: 9 Aug 89 16:07:04 GMT References: <188@latvax8.lat.oz> Sender: Tomas G. Rokicki Organization: Stanford University Lines: 118 CCMK@latvax8.lat.oz (Mark Kosten - Computer Centre, La Trobe Uni.) writes: > Has anyone got an HP DeskJet Plus DVI driver (written in something > sensible so we can use it on different oeprating systems, eg > Unix, VAX/VMS, MS-DOS)? > I know the DeskJet was a lost cause due to memory and other > limitations, but the Plus version may be just the ticket > for cheap 300dpi output. Time for my standard spiel on the DeskJet again. The HP DeskJet is a wonderful printer for use with TeX. If at all possible, get the DeskJet Plus---it is much much faster (pages take under a minute rather than two to six minutes.) Failing this, get the landscape cartridge for the DeskJet. I really don't know more than this about the landscape cartridge; it's HP22707K. The downloadable fonts for the printer are not really useful for TeX; severe restrictions on size and placement preclude their (easy) use. On the other hand, driving the printer as a bitmap engine turns out to be moderately fast and convenient. The AmigaTeX DeskJet driver is not available in source form, nor does it run on other platforms. On the other hand, the Nelson Beebe DVIJET (not DVIJEP, which is for the LaserJet Plus) driver will work with only a few modifications. The DeskJet uses standard 300 dpi fonts (75, 100, and 150 dpi aren't enough faster to ever really use.) You want to use mode_def parameters somewhat heavier than the imagen, but somewhat lighter than xerox. (I use the imagen and get acceptable output, but sometimes the strokes are a bit thin for my tastes.) Please experiment with several different types of paper---and both sides; the difference can be dramatic, especially if you are doing graphics. And here they are: First, we'll talk about output efficiency. The DeskJet allows you to specify the graphics output width---it is recommended that you scan the first 35 or so scanlines of your bitmap to find the minimum width required, and set the width with this. Then, send all the bits until you hit a patch of vertical whitespace, or the width is exceeded, or you've sent perhaps a half inch or so. (You do want to take advantage of the vertical whitespace and the narrow equation areas.) Now, we'll talk about actually building the page. The following comments are primarily directed at 640K PC's, but they are applicable to any machine as well, since memory is time. Some people have considered having a `virtual' bitmap with portions swapped out to disk. In my opinion, this is not the most efficient way to do things. Brutally pushing huge sections of bitmaps around is not terribly efficient. On the other hand, scanning a dvi page takes almost zero time. In addition, because you need to check to make sure that characters and rules lie on the page anyway, you might as well just do sections of a page at a time, and scan the dvi page multiple times. Scanning a dvi page six times takes under five seconds on a typical PC XT; the page will take a minute (on a DeskJet Plus) or two to six minutes (on a DeskJet) to print anyway. But even this approach can lead to difficulties. What if the user uses cminch at three different sizes, and a bunch of other very large characters? You'll run out of memory to store the character rasters. And much of the typical TeX page is whitespace---margins at the top and bottom, space between lines and equations---there's a lot of potential memory savings. This is what I do on the Amiga. I allocate a `raster pointer array' which has one pointer for each raster row---for 8 1/2 by 11 paper, this array has 3300 elements at 300 dpi. I initialize this array to full NULLs at the beginning of each page. I also initialize two pointers to delimit the area I'm working with---I start with these pointing to the full page (the first at the top of the page, and the last at the bottom.) Then I start reading the dvi file. As I hit each font definition, I load in the font. If I can't allocate memory for the font, I call a `freemem' routine to free up some memory until I can allocate memory. (More on freemem later.) And I continue. As I hit each character or rule drawing command, I first make sure that the character or rule lies at least partially within those two page pointers, and is on the real page. I then make sure there are raster rows allocated for the section of the bitmap, and allocate them as necessary. If I can't get memory, I call the freemem routine until I can, dynamically checking the bottom of the page bitmap (because freemem might move it.) As soon as I have the raster rows, I draw the character or rule, and continue. The freemem routine is only called if memory gets tight. It is responsible for freeing up at least one chunk of memory. It does this by looking at the page pointers---if they are within 1/10th of the page of each other, it skips to the second portion of the freemem routine. Otherwise, it decrements the page bottom pointer until it hits a raster row with an allocated row---it deallocates that row and returns. (At any time if it gets within 1/10th of a page of the top pointer, it skips to the second part.) The second part of the freemem routine deallocates fonts in an LRU manner. (LRU---each time a font is `selected', an LRU counter is incremented and assigned to a field in that font. When we go to free a font, we find the one with the smallest LRU value---and free that one.) And we return after freeing the font and marking it as unloaded. On a 640K PC, most pages won't ever call freemem---there's plenty of memory for the real page, the program, and whatever fonts are used. And when freemem is called, it's called in such a way that only two or three passes are made over the .dvi file. Only in degenerate cases like font tables is freemem called to delete fonts---and then those fonts that need deleting are deleted. It all works very well. Give it a shot!