Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: When I print using a2ps, the printed output looks as though it is not using the font that a2ps internally thinks it is using. The symptoms are lines running off the right side (no wrap, or wrap too late) and the font height a bit bigger than a nicely sized font for the same line vertical spacing. (i.e., looks like a default font is slipping into the process somewhere). I am using cups and a networked postscript printer (HP 2100M). Somehow, with release of FC3 imminent, this should work 'out of the box'. Version-Release number of selected component (if applicable): I am working with current fc3/devel yum updated files. Clean load a few weeks ago with fc3-3 (no change to a2ps config files or font files) [user1@hoho2 ~]$ a2ps --version GNU a2ps 4.13 Written by Akim Demaille, Miguel Santana. Copyright (c) 1988-1993 Miguel Santana Copyright (c) 1995-2000 Akim Demaille, Miguel Santana This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [user1@hoho2 ~]$ How reproducible: I think this same problem has existed for awhile (maybe months) Steps to Reproduce: 1. see commands below Actual results: The command below creates a single page with line numbers. Should be 10 pt font, but looking at the output, it looks bigger. The (1 line wrapped) is shown, but the first part of the line runs off the right edge and 'eadow after a shor' is totally missing on the printed page. [user1@hoho2 ~]$ a2ps -1 -f 10 --line-numbers=1 -d code.txt [code.txt (plain): 1 page on 1 sheet] request id is HP_Laser_ppd-75 (1 file(s)) [Total: 1 page on 1 sheet] sent to the default printer [1 line wrapped] [user1@hoho2 ~]$ cat code.txt #include <stuff> /* This should be a long line */ printf("%s","A quick brown fox jumped over the big green box in the meadow after a short nap"); [user1@hoho2 ~]$ Expected results: I should be able to see all of the words on the printed page. Additional info: I can attach the generated postscript file if you wish.
Confirmed with a2ps-4.13b-41.
Same problem exists on Fedora Core 3 Clean installation from CDs, move of old /old/home/user1 to /home/user1 after user1 was created in new system. I think it is also related to Mozilla printing of plain text lines - too large and Mozilla does not have the correct metric to figure out where the text is on the printed page. Note that this problem does not exist on RedHat 9.
Since my problem stemed from printing using a2ps and also shows up in Mozilla, I am focusing on CUPS as the root of the problem. Check out this extremely well written critique of CUPS - at least from the GUI and documentation thought-process point of view http://www.catb.org/~esr/writings/cups-horror.html I suspect that debugging font metrics for the default monospace font are deep in the same mire.
OK, fixed it. Gnome->System Settings->Printing->(select printer queue)->Action->Import PPD I navigated to the ppd file which came on the disk with my printer (HP 2100M). The application 'opened' it and did whatever with it. Gnome->System Settings->Printing->(select printer queue)->(button)Edit->(tab)Printer Driver This panel recommends using the pxlmono driver for my printer (HP 2100M). Since my printer IS a postscript printer, ignoring this advice and choosing the 'Postscript' printer does the trick. I also did a 'kill -HUP xxx' on the pid of every process with a 'cups' in the name. (it is like a wooden stake..) ---- Mow, both the 'code.txt' sample and pages in Mozilla with <pre> plain text print very nicely. Works for me, but there is still a problem in the 'plxmono' driver for real Postscript printers.
Created attachment 109590 [details] Broken postscript output of a2ps
The above attachment was created using a2ps as follows: a2ps foo.txt -o foo.ps This problem appears both with a2ps, enscript and firefox printing. I tried changing the printer driver to no avail. My default printer is a laserjet 1100, and I tried both hpijs and ljet4, with no discrenable difference. I'm seeing this problem on FC3.
*** This bug has been marked as a duplicate of 140584 ***