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.
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 issue 129164
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.
This really sounds like bug #237202. Here's another instance of a RHEL-5 user seeing the same problem: http://cups.org/newsgroups.php?s14787+gcups.general+v15785+T0 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 foomatic:Brother-HL-1440-hl1250.ppd 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. <==
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