Bug 524883

Summary: cpi setting not used accurately
Product: [Fedora] Fedora Reporter: Tim Waugh <twaugh>
Component: papsAssignee: Akira TAGOH <tagoh>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: fonts-bugs, i18n-bugs, iav, tagoh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 524892 537450 (view as bug list) Environment:
Last Closed: 2009-10-20 05:10:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 473302, 524892, 537450    
Attachments:
Description Flags
ppd.ppd
none
expected.jpg
none
132.txt
none
actual.jpg
none
Fixed screenshot on evince none

Description Tim Waugh 2009-09-22 15:22:04 UTC
Created attachment 362101 [details]
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.

Comment 1 Tim Waugh 2009-09-22 15:22:41 UTC
Created attachment 362103 [details]
expected.jpg

Comment 2 Tim Waugh 2009-09-22 15:23:38 UTC
Created attachment 362105 [details]
132.txt

Comment 3 Tim Waugh 2009-09-22 15:24:05 UTC
Created attachment 362106 [details]
actual.jpg

Comment 4 Akira TAGOH 2009-09-24 12:19:47 UTC
Does scaling option affect to the text printing?

Comment 5 Tim Waugh 2009-09-24 13:13:33 UTC
No, ignore 'scaling=100'.  The problem can be seen without that option.

Comment 6 Akira TAGOH 2009-09-24 14:04:15 UTC
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 10:50:56 UTC
Should be fixed in paps-0.6.8-11.fc13. please test.

Comment 8 Akira TAGOH 2009-10-19 07:54:31 UTC
Created attachment 365205 [details]
Fixed screenshot on evince

Comment 9 Akira TAGOH 2009-10-19 07:55:09 UTC
If it looks good, I'll propose the fix for f12-final too.

Comment 10 Tim Waugh 2009-10-19 10:30:38 UTC
Yes, looks perfect.  Thanks!

Comment 11 Akira TAGOH 2009-10-20 05:10:30 UTC
pushed to F-12 and tagged for f12-final now.