Presumably this also affects Red Hat Enterprise Linux 5. +++ This bug was initially created as a clone of Bug #524883 +++ Created an attachment (id=362101) ppd.ppd Description of problem: When used as texttopaps, the 'cpi' option is only used to scale the font to the nearest integer point size. This isn't nearly good enough: it must be *exact*. The reason is that it is used for controlling the number of columns of text print, and this needs to be set to e.g. 132, or 80, or whatever is required. Unfortunately the only way to set it is indirectly, via 'cpi'. Of course this depends on the page size used, as well as the printer margins. Here is a test case for verifying that it is operating correctly. The CUPS filter 'texttops' passes this test, and 'texttopaps' must as well. The test case consists of a PPD 'ppd.ppd', an input file '132.txt', and a command line given below. Version-Release number of selected component (if applicable): paps-0.6.8-10.fc12.x86_64 How reproducible: 100% Steps to Reproduce: PPD=ppd.ppd \ /usr/lib/cups/filter/texttopaps 1 tim '' 1 \ 'cpi=17.6 lpi=6.7 page-bottom=36 page-left=36 \ page-right=36 page-top=36 scaling=100' 132.txt > out.ps Actual results: See actual.jpg. Expected results: When viewing the resulting PostScript (with, say, evince), the result should look as in expected.jpg: in particular, there should be exactly 132 characters per line, and the output should fit on a single side of US Letter paper. --- Additional comment from twaugh on 2009-09-22 11:22:41 EDT --- Created an attachment (id=362103) expected.jpg --- Additional comment from twaugh on 2009-09-22 11:23:38 EDT --- Created an attachment (id=362105) 132.txt --- Additional comment from twaugh on 2009-09-22 11:24:05 EDT --- Created an attachment (id=362106) actual.jpg --- Additional comment from tagoh on 2009-09-24 08:19:47 EDT --- Does scaling option affect to the text printing? --- Additional comment from twaugh on 2009-09-24 09:13:33 EDT --- No, ignore 'scaling=100'. The problem can be seen without that option. --- Additional comment from tagoh on 2009-09-24 10:04:15 EDT --- Thanks. well, the root cause is the scaling value is a bit sensitive and the approximate width from Pango doesn't work enough. paps may needs to evaluate each lines to figure out the scale X perhaps. --- Additional comment from tagoh on 2009-10-14 06:50:56 EDT --- Should be fixed in paps-0.6.8-11.fc13. please test. --- Additional comment from tagoh on 2009-10-19 03:54:31 EDT --- Created an attachment (id=365205) Fixed screenshot on evince --- Additional comment from tagoh on 2009-10-19 03:55:09 EDT --- If it looks good, I'll propose the fix for f12-final too. --- Additional comment from twaugh on 2009-10-19 06:30:38 EDT --- Yes, looks perfect. Thanks! --- Additional comment from tagoh on 2009-10-20 01:10:30 EDT --- pushed to F-12 and tagged for f12-final now.
Created attachment 382398 [details] RPM for paps-0.6.8-12.i386.rpm This a paps rpm (taken from the rawhide branch) that appears to fix the bugs in paps-0.6.8-10 and lower. This file also requires paps-libs-0.6.8-12, something that paps-0.6.6 did not require. This is NOT a vetted patch from the RHEL team. Install at your own risk.
Created attachment 382400 [details] RPM for paps-libs-0.6.8-12.i386.rpm This a paps-libs rpm (taken from the rawhide branch) that appears to fix the bugs in paps-0.6.8-10 and lower. Note this this file also requires paps-0.6.8-12, for the texttopaps binary.
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.
As a work-around you can force CUPS to use the older texttops filter, which is not UTF-8 aware but which wraps text correctly, by creating a file like this: cat <<EOF >/etc/cups/force-texttops.convs text/plain application/postscript 1 texttops EOF After cups is next restarted it should use the CUPS texttops filter instead of the UTF-8 capable paps filter.
qa-acked.
Created attachment 471092 [details] srpm that can be builded on EL5 I rebuild rawhide srpm to form acceptable to be build on EL5
Fixed in paps-0.6.6-20.el5
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Due to an error in the scaling algorithm, running the paps utility with the "--cpi" command line option to specify the characters per inch (CPI) value did not guarantee the output to be scaled correctly. This update corrects the algorithm to work with exact values, and the output is now scaled as expected.
I think the bug was not fixed in paps-0.6.6-20.el5, I will attach the ps files generated and screencaps thereof. The command I used to test this was: PPD=ppd.ppd \ /usr/lib/cups/filter/texttopaps 1 tim '' 1 \ 'cpi=17.6 lpi=6.7 page-bottom=36 page-left=36 \ page-right=36 page-top=36 scaling=100' 132.txt > out.ps Tell me if I am doing something wrong, that's certainly possible.
Created attachment 488796 [details] Screencap of original output
Created attachment 488799 [details] Original output
Created attachment 488801 [details] Screencap of 0.6.6-20.el5 output
Created attachment 488803 [details] 0.6.6-20.el5 output
Vasiliy - was the file ppd.ppd in your current directory? If the PPD enviornment variable doesn't point to a valid PPD file, then you will get the results that you describe. Once I copied ppd.ppd to the current directory, I got the correct results.
exactly. the ppd file is supposed to be evaluated and applied by CUPS API. so if it points to the invalid file, the result has to be different.
My bad, that fixed it.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0417.html