Generic text-only printer does not work

Bug #385797 reported by Michael B. Trausch on 2009-06-11
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: cups-client

I have a Citizen 500 dot-matrix printer that I use for printing plain-text, such as source code files. The print system thinks that it knows better than I do, however, and wins the battle, refusing to print my code.

This is what happens when I attempt to print source code from lp:alltray (and remove the tabs so the printer doesn't wrap things in an ugly fashion):

Wednesday, 2009-Jun-10 at 23:44:40 - mbt@zest - Linux v2.6.30
Ubuntu Jaunty:[0-20/10022-0]:src> cat Application.vala | expand -t2 | lp -dC500
lp: Unsupported format 'application/x-csource'!

This is, of course, a plain text file. It should pass through CUPS without any issues and get to the printer without any modifications.

The printer is configured in Ubuntu as a plain (generic) text printer, since I don't intend to ever send graphics to it; just plain text. There doesn't seem to be any option for ignoring the input and just shunting print jobs directly to the printer; I'd think that would be possible for a generic text-only printer, but it doesn't seem so.

summary: - CUPS [lp(1)] does not print Vala, C source code to generic text printer
+ Generic text-only printer does not work
Till Kamppeter (till-kamppeter) wrote :

Tim, can you have a look at your "Generic Text-Only printer"? The "textonly" CUPS filter does not touch paper sizes anywhere and the PPD file has only a "Letter" paper size, no A4, nothing else. The PPD file should also have a cupsFilter lines like

*cupsFilter: "text/* 0 textonly"
*cupsFilter: "application/x-cshell 0 textonly"
*cupsFilter: "application/x-perl 0 textonly"
*cupsFilter: "application/x-shell 0 textonly"
*cupsFilter: "application/x-csource 0 textonly"

instead of

*cupsFilter: "text/plain 0 textonly"

so that all text formats defined in /etc/cups/mime.types get supported.

Another solution for the text-only printer to recognize the additional text formats would be adding the following conversion rules (for example in /usr/share/cups/mime/text.convs):

application/x-cshell text/plain 100 -
application/x-csource text/plain 100 -
application/x-perl text/plain 100 -
application/x-shell text/plain 100 -
text/html text/plain 100 -
text/css text/plain 100 -

This makes all text formats falling back to text/plain if there is no filter chain accepting the text formats themselves.

Changed in cups (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Till Kamppeter (till-kamppeter) wrote :

Added the mentioned /usr/share/cups/mime/text.convs file to the BZR repository of CUPS at Debian. So our next CUPS package will have this bug fixed.

Changed in cups (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (3.5 KiB)

This bug was fixed in the package cups - 1.3.10-3

---------------
cups (1.3.10-3) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/cups.install, debian/rules: Move added *.convs and *.types files to
    /usr/share/cups/mime/ so that they are not considered config files
    by dpkg.
  * debian/local/text.convs: Turn all text input formats to text/plain at
    a high cost, so that the text-only printer (which accepts only text/plain)
    accepts them (LP: #385797).
  * debian/rules: Switch the pdftops filter back to Poppler, as Ghostscript
    has a lot of problems in generating PostScript (LP: #382379).
  * debian/patches/poppler-based-pdftops-fixes.dpatch: Fixes for the pdftops
    filter in Poppler mode: Do not emit PostScript level 3 as it Poppler's
    PostScript level 3 output is not compatible with HP's PostScript printers
    (LP: #277404); Added support for the new "-origpagesizes" option of
    Poppler's pdftops, so that documents with pages of different sizes get
    correctly printed (LP: #310575).
  * debian/filters/pstopdf: Do not call Ghostscript with asymmetric resolutions
    (like 1200x600 dpi), as it leads to problems with images in some cases.
    See http://bugs.ghostscript.com/show_bug.cgi?id=690504.
  * debian/local/filters/pdf-filters/pdftopdf/P2PObject.h,
    debian/local/filters/pdf-filters/pdftopdf/P2POutput.cxx: Fixed infinite
    loop which occured for some PDF files (LP: #382880).
  * debian/filters/pstopdf: Make it also correctly working if PaperDimension
    and ImageableArea entries in the PPD have no translation strings. Thanks
    to Koji Otani to find the bug.
  * debian/local/filters/pdf-filters/pdftoopvp/,
    debian/local/filters/pdf-filters/README,
    debian/local/filters/pdf-filters/addtocups,
    debian/local/filters/pdf-filters/removefromcups,
    debian/local/filters/pdf-filters/config-scripts/cups-pdf-filters.m4:
    Added pdftoopvp CUPS filter as part of the PDF filter add-on.
  * debian/cups.install: Make /etc/fonts/conf.d/99pdftoopvp.conf of pdftoopvp
    be installed as part of the cups package
  * debian/control: Added build dependencies needed by pdftoopvp: liblcms1-dev,
    libfreetype6-dev, libfontconfig1-dev
  * debian/control: Moved dependency on cups-client to Depends:, as
    cups-client is needed by the post-install script for the update of the
    PPDs of existing print queues.
  * debian/cups.postinst: Case-insensitive check for model names when updating
    PPDs of already existing print queues.

  [ Martin Pitt ]
  * Add gnutls-pkgconfig.dpatch: Use "pkg-config gnutls" instead of deprecated
    libgnutls-config. (Closes: #529903)
  * Bump Standards-Version to 3.8.1 (no changes necessary).
  * debian/control: Point Vcs-Browser: to bzr.d.o. loggerhead, and use http://
    URL for Vcs-Bzr.
  * debian/control: Drop ghostscript build dependency again, pdftops filter
    uses poppler again. Also Drop alternative xpdf-utils build dependency,
    since configure now checks for poppler's pdftops capabilities.
  * debian/control, debian/rules: Do a build-time check if pdftops supports
    -origpagesizes, and dynamically set the poppler-utils dependency. This is
    a hack until https:/...

Read more...

Changed in cups (Ubuntu):
status: Fix Committed → Fix Released
Michael B. Trausch (mtrausch) wrote :

  * debian/local/text.convs: Turn all text input formats to text/plain at
    a high cost, so that the text-only printer (which accepts only text/plain)
    accepts them (LP: #385797).

I don't understand what's so costly about dumping text input straight to the printer. There shouldn't be anything required to do that. If we're whitelisting things, I think that there must be a better way.

For starters, we could identify source code correctly, with a MIME type of text/x-csource instead of application/x-csource. The latter implies that the source code may or may not be binary, when it isn't, it's source code, which _is_ plain text, not something that is costly to turn _into_ plain text. Seems like a decent stop-gap for the time being, but maybe another bug should be opened to detect formats correctly according to their major type (text, image, application, etc.)?

It also looks like the problem might be that CUPS wants to turn it into PDF as per /usr/share/cups/mime/texttopdf.convs, which contains:

Ubuntu Jaunty:[0-17/10295-0]:mime> cat texttopdf.convs
application/x-cshell application/pdf 0 texttopdf
application/x-csource application/pdf 0 texttopdf
application/x-perl application/pdf 0 texttopdf
application/x-shell application/pdf 0 texttopdf
text/plain application/pdf 0 texttopdf
text/html application/pdf 0 texttopdf

I don't see a PPD for my C500 printer (the one that is plain-text only). I have one for my e250dn, though, in the /etc/cups directory.

Till Kamppeter (till-kamppeter) wrote :

The high cost factors I have set in my new rules as these rules are only a fallback. Conversion rules taking into account the particular type of text should be preferred (they have a lower cost factor), to assure that things like prettyprint work correctly. Due to the high cost factor my rules will only be used if there is no way to get a filter path when using the particular types of text directly.

On Sat, 13 Jun 2009, Till Kamppeter wrote:

> The high cost factors I have set in my new rules as these rules are only
> a fallback. Conversion rules taking into account the particular type of
> text should be preferred (they have a lower cost factor), to assure that
> things like prettyprint work correctly. Due to the high cost factor my
> rules will only be used if there is no way to get a filter path when
> using the particular types of text directly.

Ah, so it's a virtual cost, like one can set in routing tables. Alright, my
bad.

  --- Mike

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

Other bug subscribers

Remote bug watches

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