Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
C Hemingway chemingway@semissourian.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chemingway@semissourian.com
--- Comment #3 from C Hemingway chemingway@semissourian.com 2010-01-08 01:57:55 EDT --- I believe that this bug 316461 https://bugzilla.redhat.com/show_bug.cgi?id=316461 may be related to this bug. The way the orginal tech describes the problem sounds exactly like 1) my primary use-case scenario, and 2) the effect I was experiencing. I am willing to provide test prints from two machines, one patched with the aforementioned RPM, one without it. I believe that I can prove that the wrapping calculation takes place first, and then the CPI calculation (text squishing) happens. Let me know if there is anything you need to speed getting this bug resolved.
Bug workaround: Use a2ps in the following format:
(when printing from a file) a2ps --user-option=lp --chars-per-line=132 --interpret=1 --medium=Letter -Pprinter file1 file2 file3 ... fileN
OR
(when printing from std output - note lone dash is first after command) a2ps - --user-option=lp --chars-per-line=132 --interpret=1 --medium=Letter -Pprinter
The order of the operations is very important with a2ps: --user-option=lp must be first. The option --interpret=1 is only needed if you have hard form feeds in your source document. The vertical app that our company uses does use these. If you leave off the -P parameter, the document will go to your default printer. If that's an raw print queue, prepare to waste a lot of paper. A slight problem with this is that a2ps will scale the font and maintain the aspect ratio so that while the CPI is close to 17.1 or 18, the LPI will also go from the default of 6 to 11.
If anyone finds this helpful, please log in and comment.