Red Hat Bugzilla – Bug 316461
paps text conversion has problem with calculation of the printable area
Last modified: 2010-12-28 15:16:06 EST
We use compressed printing since a lot of our reports are holdovers from the old
132 column greenbar paper days. This is usually not a problem. I use the GUI
interface to set the CPI to 17 or 18 LPI to 7,8, or 9 depending on customer
preference. I set the left and right margins to 20 and usually leave the top and
bottom margins to 36. We have multiple systems out there using these settings on
rel4 servers running the same code base. The reports print with no problems.
These systems are being converted from SCO and they also have printed correctly
for years on these systems.
On the Rel5 system compressed printing does not work. While the CPI and LPI seem
to be working correctly I do not believe that the printsystem is calculating the
printable area on the page correctly. I can get the system to print a 132
character report that wraps around by 1 char (I can tell by the dashes we use as
a break) There is plenty of room in the left and right margins. As I started to
reduce the left or right margin by one unit (each unit is a 72nd of an inch
according to what I have read) each time nothing would happen until I reach some
kind of internal boundary, at this point the report would wrap at 80 characters.
Even though the CPI and LPI are the same, the report wraps at 80, leaving the
entire right side of the page blank. Once I have reached this boundary if I
increase either the left or right margin by one it will go back to wrapping only
one char. This makes no sense to me.
Their problem sounds like it might be a bug in the filter that converts
text to PostScript. We ship 'paps' to do this, as it provides greater
support for UTF-8 text encoding than the CUPS filter 'texttops'.
They can try using the CUPS 'texttops' filter instead to see if that
avoids the problem, by changing /etc/cups/mime.convs. In that file will
be a line:
text/plain application/postscript 33 texttopaps
Change that line to read:
text/plain application/postscript 33 texttops
(i.e. remove the two characters 'a' and 'p' in 'texttopaps')
The CUPS server should be told to reload its configuration with:
/sbin/service cups reload
If that makes line-wrapping behave better then it points to a bug in the
paps package (and it would be useful to have a bug report for that in
Customer made the change and resolved the issue, hence this bug against paps.
Could you please provide a testcase and the expect result how it looks like?
As far as a reproducer goes, Dell tells us that the Customer says any
program that generates output of 132 characters per line will trigger the
bug in the paps filter. The program they're using is apparently huge, and
they can't send it to us as a reproducer.
This event sent from IssueTracker by gcase
This sort of thing can be quite hard to reproduce without the exact conditions.
I think it would help if we had a small test case consisting of:
1. a PPD file this happens with, to have the same page boundaries as the customer
2. the output of 'lpoptions -p queuename' for that queue so we can see the exact
lpi, cpi, page-left and page-right options in use
3. a few lines of text that the problem occurs with (word-wrapping bugs can be
It should be possible to see the problem from this:
PPD=theppd.ppd /usr/lib/cups/filter/texttopaps \
1 me '' 1 'cpi=17 lpi=7 page-left=36 page-right=36' \
input.txt > output.ps
with the right PPD, options, and input text file.
This really sounds like bug #237202. Here's another instance of a RHEL-5 user
seeing the same problem:
This URL may not be stable. It should point to:
Subject: [cups.general] cannot exceed 132 columns with lpd
Date: Tue, 08 Apr 2008 18:26:35 -0700
I'm using cups 1.2.4 on RHEL 5.
I'm trying to print a 135 column report from Linux to a Brother HL-1440 on a
Windows XP SP2 system, using LPD.
Per the RFC, the Windows LPD is defaulting to 132 columns in raw mode, but
according the lpr man page, the w control character I would use to override
the default is disabled.
I have tried both the standard laserjet.ppd, and the recommended
Interestingly, I could get laserjet.ppd to print up to 132 columns at
cpi=17, but the foomatic one seemed capped at 80 regardless of cpi setting.
Additionally, if I set cpi any higher than 17, or failed to specify a
page-right option, laserjet.ppd would also start wrapping at 80 columns.
I would like to be able to print 135 columns at 18 cpi. Any suggestions are
Was there any resolution to this case? I have come across the same issue with RHEL 5.4 using cups 1.3.7-11.el5_4.4