Quite a while ago, I already reported on the printer.device, and that it was the most nerve-wrecking experience we had with 3.1.4. So far, I always believed that graphics is bad, but despite it smaller size, printer made more trouble, for multiple reasons.
First, there is the Os 3.1 printer device and the new development from H&P for 3.9. Unfortunately, we do not have the 3.9 version, so this was not an option. The 3.0 version was not an option either as it does not support printing of RTG graphics - it has no clue about it. Then, there is the V58 or so version from Os 4.x, but this was not an option either because it was full of constructions that are only supported and meaningful in 4.x, such as library base access.
Hence, no good options for development. We settled for an intermediate version which was before the integration of many Os-4 specific constructions, but branched off from the V40 version from 3.1. It turned out that this wasn't a good option either, but the best we had.
The first problem we noticed was that buffer management was broken. Actually, broken in similar ways than in the 3.9 version. If you had an old slow pin-printer, you may have noticed strange artifacts at the left of the page. This happens because the printer driver renders into the output buffer while the printer is printing it, and as old parallel printers are relatively slow, the printer isn't ready before the line buffer is touched again, so 3.9 was actually unusable with anything with a slow parallel interface.
Another gymmick of the 3.9 version was that it supports multiple printers. This was re-implemented in the Os 4.x variant, and we had it. But it had the bad side-effect that whenever you opened the printer device, it would re-load the printer driver from disk. This is probably not much of an issue with harddisk users as of today, but it is clearly an anoyance if you want to print from floppy as it causes a "please insert ... in any drive", everytime you want to print. Our printer device is now smarter and buffers drivers.
Unfortunately, more issues in printer drivers remained: They all have an initialization code that opens core libraries and returns a failure code in case initialization failed. Though the printer.device never checked... so if initialization failed, the printer.device would fall over. Unfortunately, someone (ehem, Olaf) must have mis-read the documentation when implementing the HP printer drivers for 3.9. Instead of an error code and 0 for sucess, they return 1 for OK and 0 for error, quite the reverse of what is needed. This was never noticed in 3.9 because there was never any check, but for V45, there is a check and hence printer drivers from 3.9 just do not work in 3.1.4. However, we updated all of them, and the 3.1 drivers are ok in this respect. Just do not use the 3.9 drivers.
Then, Floyd-Steinberg dithering did not work as it required a larger buffer than it allocated, and then left artifacts on the right hand side of the page, at least for low resolutions. This kind of thing happens if you never attempted to print with a old-style needle printer with a stunning resolution of 90dpi. Ok, so this was noticed by our beta-team (thanks!) and hence fixed as well.
In 3.1 and 3.9, the printer.device checks for out of paper and offline conditions, but in 3.1, you could never abort printing. Yes, there was a nag requester "Printer is out of paper...", but if you attempted to abort printing, it just came back. The error was never propagated "upwards" in the code, and the only thing you could do is either insert paper - or reboot the machine. Even worse, it checked the parallel port pins just the wrong way around and hence always reported the wrong error. "Out of paper" if the printer was offline, and "offline" if the printer was out of paper. The Os 4 version also has this inverted, and while Olaf invested quite some time to make the printer abort printing, it was neither completely succesful. Just going through all the layers of the software, and checking consistently for abortion conditions is quite a hassle.
So my tests with my antique Nec P6 seem to be succesful in so far as that aborting a print now really aborts it. This is a bit touchy - you cannot simply "pull the rug" in the middle of an ESC-sequence which prints a dot graphic because if you want to continue printing later, the new commands would then be understood as part of the ESC-sequence graphics that was unfinished and part of the aborted first printer job. Apparently, Olaf missed this - you cannot just abort printing "anytime", you can only abort after the end of a control sequence.
Printing with hp printer drivers turned out also to be a hassle, even though we had updated sources, thankfully provided by Olaf who also wrote them for 3.9. Whenever we tried, graphics came out just garbled. It took a while until we found the reason: There was a silent interface change from 3.1 to Os 4.x how graphics is exchanged between the printer.device and its drivers. In 3.1 and below, the expansion of graphics (i.e. magnification to the printer resolution) is half done by the printer.device and the driver. What the driver receives is a "run-length" compressed version of the low-resolution graphics and the run sizes, i.e. two arrays: The graphics data, and the expansion factors for each pixel. For Os 4.x, the expansion factors are always 1, and the graphics is expanded by the printer.device. This allows to use old printer drivers with the new printer.device, but not using new printer drivers that do not handle expansion with the old V40 code of the printer.device we had. Hence, I also updated the hp drivers from Olaf to support the type of runlength coding used in the 3.1 world.
Then, we had similar bugs for downscaling graphics instead of upscaling graphics. If you downscale in x direction by a factor of sx, and in y direction by a factor of sy, the printer.device uses a rather naive "box filter" for the downscaling, i.e. it sums up all pixel values in boxes of size sx times sy, and then divides by the box size. Or rather, it should. In fact, it divided by sx+sy instead of sx*sy, which does, of course, just give nonsense. Strangely, nobody noticed before.
All this averaging and downscaling has several implications on HAM graphics as well: Here, the printer.device has to emulate the custom chip hardware and has to "hold and modify" pixel values itself. This is all simple if you just have single pixels, but if you also have to take averages over pixels for downscaling, things can go wrong - and did go wrong. So HAM printing was broken in V40, and probably is still broken in Os 4.x (not that these machines have HAM in first place).
The printer.device also supports a primitive form of "color correction" that, essentially, attempts to adjust between the different gamma exponents of screen and printer, and the different color densities. It's all a bit naive, but whatever... it should work, which it did not if downscaling was involved. Actually, the way how it works is that it modifies the palette before printing the image, hence - it does still not work with true color graphics or HAM, both of which do not have a palette. Speaking of true-color images, printing these images sideways was broken, too, and just generated nonsense.
So, this was really an extremely bug-ridden piece of code, and I believe there was not a single source file that remained untouched. It should be fairly ok now.
More words of warning: As already said, do not use the Os 3.9 printer drivers. They simply won't work as their initialization code returns the error indicator just the wrong way around. Use the 3.1.4 supplied drivers, which were all refactored - not only the hp drivers, also the Epson and NEC drivers were updated and cleaned up and tested. (Guess who has a NEC?). In worst case, use the Os 3.1 driver, or send me a line if you want it updated and are willing to help testing. However, they should continue to work unchanged.
A second (not-) change is the preferences system. Os 3.1.4 uses the Os 3.1 preferences system, which means that there are separate preferences files for the printer and the printer graphics configuration as these are two different preferences programs. In 3.9, this moved all to a single program and a single file. While the printer.device of 3.1.4 supports and reads the 3.9 preferences files just fine (it is just another IFF dialect) the 3.1 settings from the second preferences file override the 3.9 settings. So, either use the 3.1.4 preferences program consistently, or delete the printer preferences in ENVARC: and only use the 3.9 preferences program. Both works, but do not mix. In case of doubt, delete the printer preferences from ENVARC: and create new ones, this will work.
A feature we do not have is the printer preferences preview. This was added in the 3.9 printer.device -namely to generate a preview using the latest settings - but documentation how to do that is missing. Hence, no preview for 3.9 preferences. As soon as we find out, we may add it.
