Bug 316461

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.
PROBLEM 1
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
Bugzilla).

Customer made the change and resolved the issue, hence this bug against paps.