OK, I've done some more research; and I think I now know what's going on. I've always had excellent luck with the apsfilter/lpr combination in the past, especially with old printers. I still have install CDs for Debian Sarge laying around, which uses lpr as the print spooler. I got an old computer and installed Debian Sarge, then I installed and configured apsfilter. It did not have a driver for an IBM Proprinter II, but it did have a driver for the original IBM Proprinter. Sure enough it worked! The release of ghostscript that came with the Sarge release of Debian was 8.01. Then I looked at the "gs" command line that apsfilter used to generate the test page. In comparing it to the command line given earlier in this problem record, the key difference was the "-r" option (resolution). It turns out that the ibmpro driver generates correct output only when the -r option is specified, and only if the specified resolution is either 60x72 or 120x72. For example,
gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dSAFER -r120x72 -sDEVICE=ibmpro \ -sPAPERSIZE=letter -sOutputFile='/tmp/apsfilter10209/test_page.aps' \ setup/test.ps Notice the "-r120x72". When you specify that it generates the ESC L graphic sequence (Dual-Density Bit-Image Graphics, Half-Speed) and it does not generate those ESC * orders (set graphics mode) which are only valid on Epson printers. The ESC 3 0 sequence is still generated, (set graphics line spacing = 48/216 of an inch), but that is moot because all the forward line movements are done via ESC J ^X (hex 1B4A18), which is an explicit request to move the paper forward by 24/216 of an inch (8/72 of an inch), which is the correct spacing for 8-pin graphics. If you specify "-r60x72", it generates ESC K sequences (Normal Density Bit-Image Graphics) instead of ESC L sequences. One would think that it should support "-r240x72" too, since there is an ESC Z sequence for 240x72 resolution as well (High-Density Bit Image Graphics). But if you read the fine print on this mode, it states that it cannot print horizontally adjacent dots. Therefore, it is not a true 240x72 resolution mode. I tried the same command line using ghostscript 8.70, and it did the same thing. In summary, when using the ibmpro driver, the "-r" option must be specified, and the only two valid values are "-r60x72" and "-r120x72". If you specify one of those two options, you get valid output. If you specify any other resolution, or if you don't specify the -r option at all, you get no errors or warnings, but you get garbage output that an IBM Proprinter cannot print. By the way, the PPD file generated by foomatic for an IBM Proprinter II does not specify this option. Therefore, an IBM Proprinter II configured via the web interface of CUPS will print garbage. You can manually edit the PPD file (/etc/cups/ppd/xxx.ppd), where xxx is the name of the printer in CUPS, and specify the option. For example, change the lines in the PPD file which say *FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPA&& USE -sDEVICE=ibmpro%A%Z -sOutputFile=- -" to *FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPA&& USE -sDEVICE=ibmpro%A%Z -r120x72 -sOutputFile=- -" and now the printer will print fine. In light of this, I'm going to reassign this ticket to the foomatic-db package, which I am guessing is the right one, and let them know about the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
