Bug 524883 - cpi setting not used accurately
cpi setting not used accurately
Product: Fedora
Classification: Fedora
Component: paps (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
Depends On:
Blocks: F12Target 524892 537450
  Show dependency treegraph
Reported: 2009-09-22 11:22 EDT by Tim Waugh
Modified: 2010-12-28 19:48 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 524892 537450 (view as bug list)
Last Closed: 2009-10-20 01:10:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ppd.ppd (102.32 KB, text/plain)
2009-09-22 11:22 EDT, Tim Waugh
no flags Details
expected.jpg (323.70 KB, image/jpeg)
2009-09-22 11:22 EDT, Tim Waugh
no flags Details
132.txt (8.57 KB, text/plain)
2009-09-22 11:23 EDT, Tim Waugh
no flags Details
actual.jpg (225.52 KB, image/jpeg)
2009-09-22 11:24 EDT, Tim Waugh
no flags Details
Fixed screenshot on evince (140.15 KB, image/png)
2009-10-19 03:54 EDT, Akira TAGOH
no flags Details

  None (edit)
Description Tim Waugh 2009-09-22 11:22:04 EDT
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):

How reproducible:

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.
Comment 1 Tim Waugh 2009-09-22 11:22:41 EDT
Created attachment 362103 [details]
Comment 2 Tim Waugh 2009-09-22 11:23:38 EDT
Created attachment 362105 [details]
Comment 3 Tim Waugh 2009-09-22 11:24:05 EDT
Created attachment 362106 [details]
Comment 4 Akira TAGOH 2009-09-24 08:19:47 EDT
Does scaling option affect to the text printing?
Comment 5 Tim Waugh 2009-09-24 09:13:33 EDT
No, ignore 'scaling=100'.  The problem can be seen without that option.
Comment 6 Akira TAGOH 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.
Comment 7 Akira TAGOH 2009-10-14 06:50:56 EDT
Should be fixed in paps-0.6.8-11.fc13. please test.
Comment 8 Akira TAGOH 2009-10-19 03:54:31 EDT
Created attachment 365205 [details]
Fixed screenshot on evince
Comment 9 Akira TAGOH 2009-10-19 03:55:09 EDT
If it looks good, I'll propose the fix for f12-final too.
Comment 10 Tim Waugh 2009-10-19 06:30:38 EDT
Yes, looks perfect.  Thanks!
Comment 11 Akira TAGOH 2009-10-20 01:10:30 EDT
pushed to F-12 and tagged for f12-final now.

Note You need to log in before you can comment on or make changes to this bug.