Generic text-only printer does not work

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.

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.

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:/...

  * 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.

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