Red Hat Bugzilla – Bug 524883
cpi setting not used accurately
Last modified: 2010-12-28 19:48:57 EST
Created attachment 362101 [details]
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):
Steps to Reproduce:
/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
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.
Created attachment 362103 [details]
Created attachment 362105 [details]
Created attachment 362106 [details]
Does scaling option affect to the text printing?
No, ignore 'scaling=100'. The problem can be seen without that option.
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.
Should be fixed in paps-0.6.8-11.fc13. please test.
Created attachment 365205 [details]
Fixed screenshot on evince
If it looks good, I'll propose the fix for f12-final too.
Yes, looks perfect. Thanks!
pushed to F-12 and tagged for f12-final now.