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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
--- Comment #1 from C Hemingway chemingway@semissourian.com 2010-01-08 01:42:58 EDT --- Created an attachment (id=382398) --> (https://bugzilla.redhat.com/attachment.cgi?id=382398) 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
--- Comment #2 from C Hemingway chemingway@semissourian.com 2010-01-08 01:44:44 EDT --- Created an attachment (id=382400) --> (https://bugzilla.redhat.com/attachment.cgi?id=382400) 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
C Hemingway chemingway@semissourian.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #382398|application/octet-stream |application/x-rpm mime type| |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
C Hemingway chemingway@semissourian.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chemingway@semissourian.com
--- Comment #3 from C Hemingway chemingway@semissourian.com 2010-01-08 01:57:55 EDT --- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
--- Comment #5 from Tim Waugh twaugh@redhat.com 2010-02-12 12:34:47 EST --- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=537450
Akira TAGOH tagoh@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|chemingway@semissourian.com |eng-i18n-bugs@redhat.com |, | |fedora-i18n-bugs@redhat.com | |, | |fonts-bugs@lists.fedoraproj | |ect.org |
fonts-bugs@lists.fedoraproject.org