Printer autoconfigured, but LPR prints with to wide font/cpi setting

I have the same problem. The CUPS documentation says the default cpi is 10, but it looks like the cpi scaling is off.
If I print with lpr using default settings, I get 6 characters per inch.
If I print with lp -o cpi=10, I get 6.25 characters per inch.
If I print with lpr -o cpi=17, I get 10 characters per inch.
If I print with lpr -o cpi=20, I get 11.8 characters per inch.

So it's not just some scaling factor. But in any case, if you want the old 10 characters per inch, try lpr -o cpi=17. Maybe you can use lpoptions to set this as a default for every printer you have.

lpoptions doesn't seem to be able to set systemwide options (at least, the man page doesn't mention it). man lpoptions says options are set in /etc/cups/lpoptions, but that file doesn't exist on my karmic system. Nothing under /etc/cups seems to have "cpi" in it. Where is the default supposed to be set?

Informed upstream developer of the texttopdf filter, as this filter generates the layout and selects the font for text printouts.

The problem is not a bug in the texttopdf filter and so not a bug to be fixed in the cups package. The bug is in the FreeMono font which is provided by the ttf-freefont package. See e-mail cited below (Hin-Tak was mentor of the Google Summer of Code student who wrote texttopdf, Steve is upstream developer of the FreeMono font).

Moving to ttf-freefont ...

----------

Date: Sat, 23 Jan 2010 15:20:58 -0800 (PST)
From: Hin-Tak Leung <hintak_leung at yahoo dot co dot uk>
Subject: Bug in FreeMono - it is not monospace (Re: texttopdf has problems under CUPS 1.4.x)
To: Steve White <stevan dot white at googlemail dot com>
Cc: Till Kamppeter <till dot kamppeter at gmail dot com>

Hi Steve,

It appears that a change you committed to FreeMono about 2 years ago:

Date: Sat, 12 Apr 2008 19:39:46 +0000
 More fiddling with Greek accents
 Made quotes "bent"

has resulted in FreeMono no longer being monospace - some character spacing becomes wider/narrower. See screenshot attached (before and after) - note in the before part, every glyph lines up vertically, which is no longer the case in the after. I don't quite get the details of your change, but that's what it appears to ftview, one of freetype's viewing tools.

This problem probably isn't noticeable in mixed-font usage, but only when using FreeMono as a monospace font to typeset text and make certain assumptions about per-character-width to fit per page.

Till (of Ubuntu) passed me one of the bugs from texttopdf which was a written as a Google Summer of Code project under my guidance a year and half ago - I narrowed it down to this particular cvs change and the fact that texttopdf needs on FreeMono when typesetting in utf-8 locale, and FreeMono has changed since the project completed. I believe at the moment, the bug happens because the code assumes one width for spacing and another for fitting with a page, although I haven't found out where that assumptions are yet.

I hope you have some idea about this anomaly, and can provide a fix soon.

Cheers,
Hin-Tak

Hi,

I am investigating this, but at this time, it appears at least more complex than Hin-Tak reported. On systems at my disposal, using the same tools (ftview) he cites, FreeMono looks great. This means that either he has a somehow different copy of FreeMono from the distribution, or some other software or setting on his system is responsible for the problem.

FreeMono is in fact monospaced, in the sense that each glyph is either 600 or 0 ems wide. This can be checked with the script "isMonoMono" provided in the FreeFont package (and it is checked with all recent releases). But I don't think these two widths are the cause of Hin-Tak's problem.

Cheers!

Hin-Tak Leung and Steve White had more discussion and this has resulted in a workaround to be applied to texttopdf in the cups package. See Hin-Tak's e-mail below. The workaround is a one-byte change which I have tested now on both Karmic and Lucid where it actually solves the problem. Therefore I add a cups task for applying this workaround and nominated the bug for Karmic to include this workaround in the upcoming SRU for CUPS.

----------

Till,

I and Steve had a bit more correspondence since that e-mail. texttopdf uses the width of glyph 0 (the ".notdef" glyph) to work out the layout,
and for some reason the first few glyphs of recent FreeMono have very strange widths according to texttopdf's debug code e.g. "364 0 333 600" . freetype's ftdump also don't think it is a monospace font (possibly by a similiar method, checking the first few glyphs) so texttopdf is not alone in seeing variable widths. I sent those debug code to Steve yesterday to see if he can figure out what's going on. He noticed the ttf's real glyph data only starts at glypth 3, and the other values are supposedly made up by fontforge, so it might turn out to be a fontforge bug. (fontforge is used to generate the ttf's from sfd's.).

Meanwhile I have thought of another solution - you can replace the zero in
otf_get_width(otf,0) around texttopdf.c:1090 by say, 4. I just tried 4 here and it does the job. It doesn't matter what number it is, since a good monospace font should have the same width for most of its early glyphs. This is also a change that won't break if/when you get an updated FreeMono or use some other monospace font. (some glyphs have zero widths, like the diacritics - i.e. accent symbols which runs on top of regular glyphs, but those aren't in the beginning of the glyph list; the rest should all have the same width). I suggest you push that out as a work-around for the time-being, until the font issue itself is resolved one way or another, to keep the users happy.

Cheers,
Hin-Tak

Fix for Lucid committed to the BZR repository of CUPS at Debian.

Uploaded SRU for Karmic to the -proposed repository which is waiting for approval now. This SRU fixes this bug and also bug 407344, bug 487902, and bug 508731. debdiff is attached.

There is apparently a bug in FontForge, by which a few characters were appended to the TTF and OTF binaries of FreeFont (and other fonts). This may be partly responsible for the problems you have seen. We are onto it.

https://savannah.gnu.org/bugs/?28742

This bug was fixed in the package cups - 1.4.2-7

---------------
cups (1.4.2-7) unstable; urgency=low

  [ Till Kamppeter ]
  * debian/local/filters/pdf-filters/filter/texttopdf.c: Workaround for
    bug in ttf-freefont which messed up the output of the texttopdf filter.
    Thanks to Hin-Tak Leung and Steve White to find this solution (LP: #447961).
  * debian/local/filters/pdf-filters/pdftopdf/P2PDoc.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2PGfx.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2PGfx.h,
    debian/local/filters/pdf-filters/pdftopdf/P2PObject.h,
    debian/local/filters/pdf-filters/pdftopdf/P2POutput.cxx: Upstream
    fix from Koji Otani for the following: (1) Fixed some memory leak;
    (2) pdftopdf now delays fetching a referenced object until when it is
    written to the output. This fixes memory hogging with N-up output
    (N pages per sheet). The fix is mainly done by (2). This fixes
    LP: #508731.

  [ Martin Pitt ]
  * manpage-translations.dpatch: Update to German manpage translations, thanks
    Helge Kreutzmann! (Closes: #502908)
  * debian/cups.postinst: Do not symlink snakeoil SSL certificate if
    server.{crt,key} already exist as broken symlinks. Thanks Andreas
    Büsching! (Closes: #554579)
 -- Martin Pitt <email address hidden> Wed, 27 Jan 2010 09:19:32 +0100

Accepted cups into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

The font width problem has been reported as bug # 474962 and as bug # 485665. One place focuses on the number of chars per line, while the other one focuses on the char width.

It looks like someone has put a duplicate bug notice on 474962, but there is not yet one up on 485665. I just refreshed the bug page for the later one and it now has a duplicate bug notice posted as well.

Thanks to everyone who has been working on this.

Just found another bug # reporting the fontwidth problem: bug # 488268
.

I followed the instructions above to go to the link that explains how to set things up to install the package from -proposed.

My /etc/apt/lists.conf has

# Proposed

deb http://archive.ubuntu.com/ubuntu/ karmic-proposed restricted main multiverse universe

at the end of the file.

The GUI for adding repos shows it checked, but when I search on cups in synaptic I am not presented with any cups newer than 1.4.1-5ubuntu21 or whatever. If I run the command line aptitude above I do not find any new version when I search in that menu either.

Since I am not sure what packagename I need to get I have not tried the commandline 'sudo aptitude packagename/karmic-proposed' .

Any idea why I do not see the package?

I have checked the server and the new CUPS packages are there.

Can you run the command

sudo apt-get update

in a terminal window? Can you download the updated CUPS now?

Thanks. I have been away from ubuntu for awhile and am rusty, so forgot to do that. I have now done it, saw that all the repos updated. Saw the lines:

Hit http://archive.ubuntu.com karmic-proposed/main Packages
Hit http://archive.ubuntu.com karmic-proposed/multiverse Packages
Hit http://archive.ubuntu.com karmic-proposed/universe Packages

on the console.

Looked at both synaptics and aptitude and searched all the way through every instance of the word cups returned by their search routines and could not find any cups anything newer than 1.4.1-5*.

In addition to adding karmic-proposed to sources.list, I also created the file /etc/apt/preferences according to the howto. Could that be related?

I was able to install the above update. The presence of /etc/apt/preferences with a priority of 400 was, I believe, causing synaptic to hide it. I may also have been confused about the package name. I was looking for cups1.4.2-7, but the ubuntu number still starts out as 1.4.1-5Ubuntu2.2.

Once I got that straightened out then I was able to update with synaptics. I might have been able to do it with aptitude to begin with. Then I mv'ed preferences to preferences-SAVE.

I just printed /etc/hosts and a very simple shell script (#!/bin/sh on one line, simple command on next line) and both printed in the proper 10 cpi courier-looking font. I have not tried printing to a PDF yet.

However, I would like to be able to pass text files directly to the printer without rasterizing it. -o raw doesn't work because LF needs to be changed to CR-LF. Raw text files print about twice as dark as the text files that are rasterized by cups.

Thank you all for at least straightening out the original bug.

Thank you, Stew, for confirming that the SRU fixes this bug. We will soon add it to the automatic updates.

Passing text directly to the printer is not a bug but a feature request. This feature request is not specific to Ubuntu but interesting for users of all distributions, especially users of dot matrix printers. Therefore post a feature request at

http://www.cups.org/str.php

Confirming that this work-around installs and reconfigures via

enable the proposed repository following: https://wiki.ubuntu.com/Testing/EnableProposed
$ sudo apt-get install cups

and that this fixes the character width bug.

Linux tp400-64 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
Fully updated Karmic Koala AMD64.

This bug was fixed in the package cups - 1.4.1-5ubuntu2.2

---------------
cups (1.4.1-5ubuntu2.2) karmic-proposed; urgency=low

  * debian/local/filters/pdf-filters/filter/texttopdf.c: Workaround for
    bug in ttf-freefont which messed up the output of the texttopdf filter.
    Thanks to Hin-Tak Leung and Steve White to find this solution (LP: #447961).
  * debian/local/filters/pdf-filters/pdftopdf/P2PDoc.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2PGfx.cxx,
    debian/local/filters/pdf-filters/pdftopdf/P2PGfx.h,
    debian/local/filters/pdf-filters/pdftopdf/P2PObject.h,
    debian/local/filters/pdf-filters/pdftopdf/P2POutput.cxx: Upstream
    fix from Koji Otani for the following: (1) Fixed some memory leak;
    (2) pdftopdf now delays fetching a referenced object until when it is
    written to the output. This fixes memory hogging with N-up output
    (N pages per sheet). The fix is mainly done by (2). This fixes
    LP: #508731.
  * debian/local/filters/pdf-filters/pdftopdf/P2PGfx.cxx: Fixed segfault of
    the pdftopdf filter when the input PDF file has ICC-profile-based color
    space inline images. Thanks to Koji Otani for the fix. Fixes LP: #407344.
  * debian/local/filters/cpdftocps: Fixed turning off duplex via command line
    (http://bugs.linux-foundation.org/show_bug.cgi?id=397, LP: #487902).
 -- Till Kamppeter <email address hidden> Tue, 26 Jan 2010 12:10:20 +0100