text prints in wide font, errors logged

Bug #474962 reported by Matt Warnock
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: cups

Just upgraded from ubuntu 9.04 to 9.10 on two separate machines in the usual do-release-upgrade way.
Text printing is broken on both machines, in the same strange way.
cups is 1.4.1-5ubuntu2

To reproduce:
cat /etc/motd | lp
produces printing in a wide font (6 cpi) and two error messages in /var/log/cups/error_log:
"Unterminated string"
"End of file inside dictionary"
These appear to me to be postscript errors.
The same result obtains no matter what printer is selected, and whether text is piped
or a text file is printed. Test pages and postscript files print just fine.

At first I thought the text-to-ps filter was to blame, but:
cat /etc/motd | /usr/lib/cups/filter/texttops 1234 user title 1 - | lp
will produce the normal expected (10cpi) output.

I don't know the control flow of cups well enough to nail it down further.

Revision history for this message
Matt Warnock (mwarnock) wrote :

Both upgrades reported yesterday were to servers running AMD64 version. Installed 9.04 fresh from CD using i386, same result confirmed. Text printing is seriously broken in 9.10. Any workarounds or fixes?

Revision history for this message
Ian Hutchinson (hutch) wrote :

Confirming that Karmic Koala AMD64 text printing is broken. The text comes out with a ridiculous wide font
that overflows the side of the page. I tried setting the cpi and lpi values, but that did not fix the problem.
Please can someone give us some advice on how to work around or fix this bug.

Revision history for this message
Trevor Christensen (trevor-jcmanagement) wrote :

I've been looking for a comment/solution on this for 1.5 months. This is a very inconvenient problem. As above, I have tried numerous settings/changes/etc. without success. This occurs for me on new installations and upgraded installations.

Ubuntu 9.10 (karmic)
2.28.1 (Ubuntu 2009-11-03)
2.6.31-17-generic (#54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009)
Intel(R) Pentium(R) 4 CPU 2.00GHz
2019.801 MHz
512 KB

Revision history for this message
Stew Ellis (ellis-kettering) wrote :

Just installed ubuntu 9.10 AMD64 version on Intel Core 2 quad on Intel DG41TY mobo. With both the version of cups listed above and the upgrade to 1.4*21 get the same 6cpi on a lexmark e260dn using either the lexmark ppd or hplj4 ppd (non plus) or apple laserwriter ppd. Yesterday I started playing around with lp -o cpi=n settings, and if cpi=10 (explicitly set same as default) I got the 6cpi. cpi=20 was 12 cpi, so I kept fiddling until I empirically determined that cpi=16 produced 10cpi. It is workable, but it is so wrong. you can either hand edit /etc/cups/lpoptions or it is easier to set by running 'lpoptions -o cpi=16' as root for each printer ( use the -d printername before the -o cpi). OpenSUSE 11.2 does not do this, but I did not notice what version of cups it was on.

Revision history for this message
Stew Ellis (ellis-kettering) wrote :

More testing. Suggested fix sent to me in private email. It definitely has to do with the flow of filters.

My above suggestion is definitely a kluge. You should not have to lie to the cups system about the font width. Someone else emailed me privately with a different kluge that involved commenting out lines in /usr/share/cups/mime/texttopdf.convs for text/plain and for text/html. I did that but lp'ed a simple sh script and it was in the 6 cpi format again. To stop Karmic cups from munging text files you would have to comment out every kind of text file type listed in that file. When all are commented out then text files would be sent to the printer without conversion, which is what he and I want, but rather than frustrate whatever part of the filter chain is looking in texttopdf.convs for what to do, I would rather have the printing system check if it is a textfile, then do no additional filtering and send direct to the printer for those printers that can print text without it being rasterized first.

One thing I notice is that none of the openSuSEs that I have run in the last several years has a texttopdf.convs file, while both versions of Ubuntu (linuxmint version of 7.04 and current 9.10) have the file. cups worked properly in 7.04 with the same convs file as in the current version. printers.conf in Karmic has 3 filter commands for each defined printer, whereas none of SuSE 10.1 and 11.1 and 7.04 have filter directives in printers.conf. I have tried to read the cups manuals, but have not found any discussion of default handling of text files.

Is this a problem with Ubuntu only or also upstream to Debian?

Long time since I have done any serious debugging. What is the best set of tools to try to trace when and where filters are being used and what they are chaining to?

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Please try the fix proposed in bug 447961. If you are on Karmic, install the SRU (Stable Release Update) of cups in -proposed as instructed there and give your feedback. DO NOT modify any config files, like printers.conf or the *.convs and *.types files.

The problem also occurs in Debian Linux as there the same CUPS package with the same filters is used. The fix is also uploaded to Debian unstable.

For analyzing filter chains look into the error_log of CUPS. Set CUPS to debug logging mode via

cupsctl LogLevel=debug

and send a print job. Then the filter calls get logged in the error_log.

Revision history for this message
Stew Ellis (ellis-kettering) wrote :

This is the same bug as reported differently under number 485665. There they characterize the problem as printing 47 chars per 80 char line. 47/80 is 5.875 which we have seen as 6 cpi.

Revision history for this message
Matt Warnock (mwarnock) wrote : Re: [Bug 474962] Re: text prints in wide font, errors logged

This is definitely not a problem in Debian stable, I can't speak for
Debian testing or Sid.

This may be acceptable on a desktop, where users work in PDF and
Postscript, but not for a production print server, and exactly why I
have STOPPED using Ubuntu server in production.

On Wed, 2010-02-03 at 16:47 +0000, Stew Ellis wrote:
> More testing. Suggested fix sent to me in private email. It definitely
> has to do with the flow of filters.
>
> My above suggestion is definitely a kluge. You should not have to lie
> to the cups system about the font width. Someone else emailed me
> privately with a different kluge that involved commenting out lines in
> /usr/share/cups/mime/texttopdf.convs for text/plain and for text/html.
> I did that but lp'ed a simple sh script and it was in the 6 cpi format
> again. To stop Karmic cups from munging text files you would have to
> comment out every kind of text file type listed in that file. When all
> are commented out then text files would be sent to the printer without
> conversion, which is what he and I want, but rather than frustrate
> whatever part of the filter chain is looking in texttopdf.convs for what
> to do, I would rather have the printing system check if it is a
> textfile, then do no additional filtering and send direct to the printer
> for those printers that can print text without it being rasterized
> first.
>
> One thing I notice is that none of the openSuSEs that I have run in the
> last several years has a texttopdf.convs file, while both versions of
> Ubuntu (linuxmint version of 7.04 and current 9.10) have the file. cups
> worked properly in 7.04 with the same convs file as in the current
> version. printers.conf in Karmic has 3 filter commands for each defined
> printer, whereas none of SuSE 10.1 and 11.1 and 7.04 have filter
> directives in printers.conf. I have tried to read the cups manuals, but
> have not found any discussion of default handling of text files.
>
> Is this a problem with Ubuntu only or also upstream to Debian?
>
> Long time since I have done any serious debugging. What is the best set
> of tools to try to trace when and where filters are being used and what
> they are chaining to?
>

--
Matt Warnock <email address hidden>
RidgeCrest Herbals, Inc.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.