Bug 316461 - paps text conversion has problem with calculation of the printable area
paps text conversion has problem with calculation of the printable area
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: paps (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
QE Internationalization Bugs
Depends On:
  Show dependency treegraph
Reported: 2007-10-03 02:26 EDT by Norm Murray
Modified: 2010-12-28 15:16 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-01 15:12:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Norm Murray 2007-10-03 02:26:27 EDT
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.
Comment 1 Akira TAGOH 2007-10-04 06:52:21 EDT
Could you please provide a testcase and the expect result how it looks like?
Comment 3 Issue Tracker 2007-10-17 11:38:02 EDT
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 
 issue 129164
Comment 4 Tim Waugh 2007-10-17 13:23:40 EDT
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
quite content-dependent)

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.
Comment 8 Tim Waugh 2008-04-09 04:43:06 EDT
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 
greatly appreciated. 
Comment 10 tnunemaker 2009-11-27 13:34:31 EST
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

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