Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: cpi setting not used accurately
https://bugzilla.redhat.com/show_bug.cgi?id=537450
Summary: cpi setting not used accurately Product: Red Hat Enterprise Linux 5 Version: 5.4 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: paps AssignedTo: tagoh@redhat.com ReportedBy: twaugh@redhat.com QAContact: desktop-bugs@redhat.com CC: tagoh@redhat.com, fedora-fonts-bugs-list@redhat.com, fedora-i18n-bugs@redhat.com Depends on: 524883 Classification: Red Hat Target Release: --- Clone Of: 524883
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) --> (https://bugzilla.redhat.com/attachment.cgi?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@redhat.com on 2009-09-22 11:22:41 EDT ---
Created an attachment (id=362103) --> (https://bugzilla.redhat.com/attachment.cgi?id=362103) expected.jpg
--- Additional comment from twaugh@redhat.com on 2009-09-22 11:23:38 EDT ---
Created an attachment (id=362105) --> (https://bugzilla.redhat.com/attachment.cgi?id=362105) 132.txt
--- Additional comment from twaugh@redhat.com on 2009-09-22 11:24:05 EDT ---
Created an attachment (id=362106) --> (https://bugzilla.redhat.com/attachment.cgi?id=362106) actual.jpg
--- Additional comment from tagoh@redhat.com on 2009-09-24 08:19:47 EDT ---
Does scaling option affect to the text printing?
--- Additional comment from twaugh@redhat.com on 2009-09-24 09:13:33 EDT ---
No, ignore 'scaling=100'. The problem can be seen without that option.
--- Additional comment from tagoh@redhat.com 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@redhat.com on 2009-10-14 06:50:56 EDT ---
Should be fixed in paps-0.6.8-11.fc13. please test.
--- Additional comment from tagoh@redhat.com on 2009-10-19 03:54:31 EDT ---
Created an attachment (id=365205) --> (https://bugzilla.redhat.com/attachment.cgi?id=365205) Fixed screenshot on evince
--- Additional comment from tagoh@redhat.com 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@redhat.com on 2009-10-19 06:30:38 EDT ---
Yes, looks perfect. Thanks!
--- Additional comment from tagoh@redhat.com on 2009-10-20 01:10:30 EDT ---
pushed to F-12 and tagged for f12-final now.