dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (12/22/88)
Apologies if some of this sounds like a flame, it might be. The source examples for the printers are missing a file in each directory. each file is INCLUDEd by the assembly to setup EQU's for the VERSION and REVISION... if you attempt to assemble the source you will get an assembly error, the assembler not being able to find the non-existant file. VERSION must be set to 35 or 1.3 will not recognize the printer.device as being a 1.3 printer device REVISION is not restricted (make it 0?) Additionaly, one of the assembly files XREF's a routine (forgot the name) which does not exist... just remove the XREF when you get the assembly error. Aztec C / Lattice users: Compile with the Large Data model Aztec C users: Compile .C modules +BDLp and assembly modules -D +B Do not reference .begin +D Large-Data model (A4 will not be set properly) +L 32 bit integers +p save/restore D2/D3 -D Large-Data model for assembly files NOTE: A6 may or may not have to be preserved. I do not know what the printer.device assumes. If it does, you need to tag the C routines to save and restore A6 (write some assembly that calls the C routines instead of the printer.device calling them directly). --- Finally, the EpsonQ implementation is all wrong for the LQ500. It works, but doesn't work as well as it could. There is no explanation of printer.device workings and call parameters in either the source or docs. For example, nowhere does it say which DoSpecial() codes are called even when there is no \377 in the conversion table. Nowhere is it described what the difference between returning 0 and -1 causes (I had to figure that one out...) Nowhere does it describe what those extra char *parameters to DoSpecial: char *vline, and *currentVMI actually mean. Are they there just for something we can fool around with or does the printer.device actually use them? There is no clear explanation as to what the various control codes are supposed to effect. For instance, what exactly is aRIN supposed to reset? Is it supposed to reset the tabs? font? margins? paper size? just the various enhancement modes? Nobody knows for sure and there are some things the example printer drivers DON'T do that seem all wrong. What about all the other things. For example, if you turn on Elite and then turn it off, should the printer driver go to 10Pitch or the previous or preferences Pitch? is aSHORP0 (normal pitch) mean 10 pitch or the preferences Pitch? There is no explanation as to the duration of many of the enhancement modes. Does it last just a line? until it is turned off? what? All of these might be some kind of ansi standard, but I doubt anybody has a handbook describing the proper operation of the codes. When in condensed fine, 8 lpi leaves huge vertical spaces between character lines. Obviously this is incorrect because there is no other escape code get a smaller lpi. Realistically setting 6 LPI mode when in condensed fine ought to actually set 8 LPI, and setting 8 LPI mode when in condensed fine ought to actually set 10 LPI... otherwise the space is totally wasted and people will bypass the driver to fix it. There is no way to be able to inform the application program what the current printer limits in terms of lines on the page, columns, etc... are, meaning that application programmers must STILL have some kind of internal printer list so they can figure out what is going on. The graphics are better .... application programs can now sort of query the driver. There is no way to inform the application program which codes are implemented and which are not. Should user margins be enforced when making graphics dumps? What about mixing graphics with text? How do you offset the graphics image and prevent a line feed? (i.e. tab tab graphics <CR> text linefeed repeat). If these things are not described nobody writing printer drivers will know to put them in. Finally, permission has been granted only to distribute executables of printer drivers based on the 1.3 examples. I want to be able to distribute fixed source. -Matt
page@swan.ulowell.edu (Bob Page) (12/23/88)
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) wrote: >the EpsonQ implementation is all wrong for the LQ500. >It works, but doesn't work as well as it could. I'd say it isn't all wrong then. Could you describe what problems it has? I'm interested in this driver; I just picked up an Epson L-1000, apparently this year's model of the LQ500. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page Have five nice days.