Shallow Thoughts : tags : printing

Using a Driverless Printer on Debian (Without Avahi)

It's nice to be back on a relatively minimal Debian install, instead of Ubuntu-with-everything. But one thing that I have to admit I appreciated about Ubuntu: printing "just worked". Turn on a printer, call up the print menu in any app, and the printer I turned on would be there in the menu, without any need of struggling with CUPS configurations.

Ubuntu was using Avahi, the Linux version of Apple's Zeroconf/Bonjour framework, to discover printers. I knew that I'd probably need to install Avahi if I wanted easy printer configuration on Debian. But as it turned out, getting printing working was both harder, and easier.

Read more ...

Tags: linux, debian, cups, printing
[ 18:14 Feb 11, 2022    More linux | permalink to this entry | ]

Printing Two-Sided from the Command Line

The laser printers we bought recently can print on both sides of the page. Nice feature! I've never had access to a printer that can do that before.

But that requires figuring out how to tell the printer to do the right thing. Reading the man page for lp, I spotted the sides option: print -o sides=two-sided-long-edge. But that doesn't work by itself. Adding -n 2 looked like the way to go, but nope! That gives you one sheet that has page 1 on both sides, and a second sheet that has page 2 on both sides. Because of course that's what a normal person would want. Right.

The real answer, after further research and experimentation, turned out to be the collate=true option:

lp -o sides=two-sided-long-edge -o collate=true -d printername file

Tags: linux, cmdline, printing
[ 11:05 Sep 16, 2018    More linux | permalink to this entry | ]

Tricks for Installing a Laser Printer on Linux in CUPS

(Wherein I rant about how bad CUPS has become.)

I had to set up two new printers recently. CUPS hasn't gotten any better since the last time I bought a printer, maybe five years ago; in fact, it's gotten quite a bit worse. I'm amazed at how difficult it was to add these fairly standard laser printers, both of which I'd researched beforehand to make sure they worked with Linux.

It took me about three hours for the first printer. The second one, a few weeks later, "only" took about 45 minutes ... at which point I realized I'd better write everything down so it'll be faster if I need to do it again, or if I get the silly notion that I might want to print from another computer, like my laptop.

I used the CUPS web interface; I didn't try any of the command-line tools.

Figure out the connection type

In the CUPS web interface, after you log in and click on Administration, whether you click on Find New Printers or Add Printer, you're faced with a bunch of identical options with no clue how to choose between them. For example, Find New Printers with a Dell E310dw connected shows:

Available Printers

• [Add This Printer] Virtual Braille BRF Printer (CUPS-BRF)
• [Add This Printer] Dell Printer E310dw (Dell Printer E310dw)
• [Add This Printer] Dell Printer E310dw (Dell Printer E310dw)
• [Add This Printer] Dell Printer E310dw (Dell Printer E310dw (driverless))

What is a normal human supposed to do with this? What's the difference between the three E210dw entries and which one am I supposed to choose? (Skipping ahead: None of them.) And why is it finding a virtual Braille BRF Printer?

The only way to find out the difference is to choose one, click on Next and look carefully at the URL. For the three E310dw options above, that gives:

• dnssd://Dell%20Printer%20E310dw._ipp._tcp.local/?uuid=[long uuid here]
• lpd://DELL316BAA/BINARY_P1
• ipp://DELL316BAA.local:631/ipp/print

Again skipping ahead: none of those are actually right. Go ahead, try all three of them and see. You'll get error messages about empty PPD files. But while you're trying them, write down, for each one, the URL listed as Connection (something like the dnssd:, lpd: or ipp: URLs listed above); and note, in the driver list after you click on your manufacturer, how many entries there are for your printer model, and where they show up in the list. You'll need that information later.

Download some drivers

Muttering about the idiocy of all this -- why ship empty drivers that won't install? Why not just omit drivers if they're not available? Why use the exact same name for three different printer entries and four different driver entries? -- the next step is to download and install the manufacturer's drivers. If you're on anything but Redhat, you'll probably either need to download an RPM and unpack it, or else google for the hidden .deb files that exist on both Dell's and Brother's websites that their sites won't actually find for you.

It might seem like you could just grab the PPD from inside those RPM files and put it wherever CUPS is finding empty ones, but I never got that to work. Much as I dislike installing proprietary .deb files, for both printers that was the only method I found that worked. Both Dell and Brother have two different packages to install. Why two and what's the difference? I don't know.

Once you've installed the printer driver packages, you can go back to the CUPS Add Printer screen. Which hasn't gotten any clearer than before. But for both the Brother and the Dell, ipp: is the only printer protocol that worked. So try each entry until you find the one that starts with ipp:.

Set up an IP address and the correct URL

But wait, you're not done. Because CUPS gives you a URL like ipp://DELL316BAA.local:631/ipp/print, and whatever that .local thing is, it doesn't work. You'll be able to install the printer, but when you try to print to it it fails with "unable to locate printer".

(.local apparently has something to do with assuming you're running a daemon that does "Bonjour", the latest name for the Apple service discovery protocol that was originally called Rendezvous, then renamed to Zeroconf, then to Bonjour. On Linux it's called Avahi, but even with an Avahi daemon this .local thing didn't work for me. At least it made me realize that I had the useless Avahi daemon running, so now I can remove it.).

So go back to Add Printer and click on Internet Printing Protocol (ipp) under Other network printers and click Continue. That takes you to a screen that suggests that you want URLs like:

http://hostname:631/ipp/
http://hostname:631/ipp/port1

ipp://hostname/ipp/
ipp://hostname/ipp/port1

lpd://hostname/queue

socket://hostname
socket://hostname:9100

None of these is actually right. What these printers want -- at least, what both the Brother and the Dell wanted -- was ipp://printerhostname:631/ipp/print

printerhostname? Oh, did I forget to mention static IP? I definitely recommend that you make a static IP for your printer, or at least add it to your router's DHCP list so it always gets the same address. Then you can make an entry in /etc/hosts for printerhostname. I guess that .local thing was supposed to compensate for an address that changes all the time, which might be a nifty idea if it worked, but since it doesn't, make a static IP and use it in your ipp: URL.

Choose a driver

Now, finally! you can move on to choosing a driver. After you pick the manufacturer, you'll be presented with a list that probably includes at least three entries for your printer model. Here's where it helps if you paid attention to how the list looked before you installed the manufacturer's drivers: if there's a new entry for your printer that wasn't there before, that's the non-empty one you want. If there are two or more new entries for your printer that weren't there before, as there were for the Dell ... shrug, all you can do is pick one and hope.

Of course, once you manage to get through configuration to "Printer successfully added", you should immediately run Maintenance->Print Test Page. You may have to power cycle the printer first since it has probably gone to sleep while you were fighting with CUPS.

All this took me maybe three hours the first time, but it only took me about 45 minutes the second time. Hopefully now that I've written this, it'll be much faster next time. At least if I don't succumb to the siren song of thinking a fairly standard laser printer ought to have a driver that's already in CUPS, like they did a decade ago, instead of always needing a download from the manufacturer.

If laser printers are this hard I don't even want to think about what it's like to install a photo printer on Linux these days.

Tags: linux, printing, cups, rant
[ 16:19 Jan 25, 2018    More linux | permalink to this entry | ]

Printing in Landscape orientation in GIMP (and some spinbutton tips)

I was printing out a map for a new trail we wanted to hike. I wanted to fill the paper with the map -- Google maps' print and Firefox's print, while fine for most map printing, weren't what I wanted.

So I took a screenshot of the maximized browser window with the map in it and imported it into GIMP. In the Crop tool, I constrained Aspect-ratio to 11:8.5 and cropped the image so it would just fit on a page, in landscape format -- wider in east-west than in north-south. Then I chose File->Print.

Since printing defaults to Portrait orientation, I went to the Page Setup tab and changed Orientation to Landscape. (It's so nice to have that as part of the dialog. I'm forever amazed at how some apps, like Firefox, make you use a separate dialog first to change the print's orientation. How can anyone possibly see that as sensible UI design?)

Unfortunately, When I went to the Image Settings tab to check , I discovered that GIMP hadn't adjusted the image size when I changed to Landscape. It had Width listed as 8.500, Height as 6.567, and the image only took up part of the page.

I went to the Width field and replaced 8.500 with 11, and hit Tab. Whoops! The field reverted to 8.500. The same thing happened if I tried typing 8.5 into the Height field.

These fields aren't plain text entries -- they're "spin boxes", with a text entry plus up and down arrows. It turned out that under GIMP 2.8 and earlier, round-off errors sometimes prevent you from setting a spin box's maximum value. I could type 10.999 and it would work fine, but 11 or 11.0 failed.

Of course, 10.999 would have been fine -- I don't mind a little margin on a printed map. It's also trivial in GIMP to rotate a landscape photo 90 degrees and print it in portrait orientation. But by this point I was into stubborn mode -- by gosh, I wanted a way to fix this!

The best workaround, it turns out, is to use the spin box's up-arrow. Holding the mouse down over the up arrow will eventually get to the maximum value. But there's a faster way: right-clicking on the up-arrow goes straight to the maximum value. A nice trick!

The problem doesn't exist in GIMP 2.9 -- I reported it as bug 694477, and the awesome GIMP team fixed it very quickly. The spin boxes work beautifully now. (Thanks, Mitch!) But as long as 2.8 is around, or for any other app using spin boxes, I'm glad to know about right-clicking on the spin box arrows.

Tags: gimp, printing
[ 12:26 Feb 27, 2013    More gimp | permalink to this entry | ]

Helpful CUPS error messages, decoded

Another in the continuing series of "This isn't documented anywhere and Google searches aren't helpful":

Dave's printer was failing to print on Ubuntu Lucid. The only failure mode: pages came out with the single printed line,

Unable to open the initial device, quitting.

What a great, helpful error message! Thanks, CUPS!

Web searching found lots of people using HP printers, using various versions of the HPLIP software to installer newer drivers and otherwise reconfigure their HP setups.

Only problem: this printer isn't an HP. It's a Brother HL2070N, which has given very good service and, until now, worked flawlessly with every OS we've tried including Linux.

The solution? It turns out the problem really is HPLIP -- even if the printer isn't an HP. What this message really meant was:

HPLIP isn't installed, and Ubuntu's CUPS refuses to work without it.

apt-get install hplip hplip-data got the printer working again.

Wouldn't it be nice if CUPS bothered to print error messages that gave some hint of the real problem? Ideally, visible on the computer to the user, rather than on the printed page, so you don't have to waste 25 pages of dead tree while you try to narrow down the problem?

Update: After further testing, we have established that a standard Gnome-based Ubuntu Lucid machine needs hplip and hplip-data installed, while a Lucid machine without Gnome needs those two plus hpijs. Or you can get around needing any of them by ignoring CUPS' recommendation for which driver to use, and choosing the Gutenprint driver in the CUPS configuration screens.

A reader asked me if we had checked the CUPS error log. On one machine, the log file was virtually empty; on another, there actually were some lines about hpijs (nothing about hplip), intermixed with a lot of debug chatter and a large number of errors that were fairly clearly unrelated to anything we were doing.

Tags: linux, printing, cups
[ 22:46 Jun 22, 2010    More linux | permalink to this entry | ]

Firefox printer preferences: the novel

I discovered recently that 1067 lines in my Firefox preferences file (out of 1438 total) were devoted to duplicating default printer settings.

I got a new printer recently. I needed to set up a preference in user.js so I can switch temporarily to landscape mode printing without having landscape mode become permanent. So I checked in on prefs.js to see what Firefox called my new printer -- and, well, eek!

For every printer I've ever used on this machine, I had a set of options that looked like this:

user_pref("print.printer_Epson.print_bgcolor", false);
user_pref("print.printer_Epson.print_bgimages", false);
user_pref("print.printer_Epson.print_colorspace", "default");
user_pref("print.printer_Epson.print_command", "lpr ${MOZ_PRINTER_NAME:+-P\"$MOZ_PRINTER_NAME\"}");
user_pref("print.printer_Epson.print_margin_bottom", "0.500000012107193");
user_pref("print.printer_Epson.print_margin_left", "0.500000012107193");

and so on -- 41 lines, in the case of print.printer_Epson. But some printers had multiple sets of preferences -- here's the list of printer names, each of which had those 41 lines, more or less:

• printer_Brother
• printer_CUPS/Brother
• printer_CUPS/Epson
• printer_CUPS/epson
• printer_Epson
• printer_PostScript/default
• printer_Print_to_File
• printer_Deskjet-F4200-series
• printer_HP_Deskjet_F4200_series

In case you're curious, this encompasses three physical printers I've used with Firefox: my old Epson C86, my new HP F4280, and Dave's Brother HL 2070N. None of these values is anything I've ever set myself; they're all default values.

Why Firefox feels the need to store them for all eternity is anybody's guess.

But wait, you say ... 41 lines times 9 printers is a lot, but it doesn't come close to equalling 1067 lines. What else is there?

Well, there are another 43 lines that repeat all those same defaults again but don't specify any particular printer, like user_pref("print.print_footerleft", "&PT");.

And then, oh wait, what's this? All the preceding prefs are duplicated all over again, with "tmp" added, like this:

user_pref("print.tmp.printerfeatures.Brother_HL-2070N_series.supports_paper_size
_change", true);
user_pref("print.tmp.printerfeatures.CUPS/Brother.orientation.count", 2);

and so on. 456 lines of that.

Unfortunately, I got a little over-zealous in deleting lines before I'd made a backup of the original file. So by the time it occurred to me to write this up, I'd destroyed some of the evidence and had to work from a backup, which "only" had 813 lines of print preferences. Part of that is that I didn't have the new printer yet (two entries times 41 lines times two) but that only gets me up to 977 lines. I'm not sure what the other 190 lines were.

How many printing preferences do you have? You can see them by going to about:config and typing print. Or on Linux, you can count them. First find your profile folder, where your prefs.js file lives, or search for prefs.js directly:

locate prefs.js | grep home

Then use wc on that prefs.js file to count your print preference lines:

grep print yourprofile/prefs.js | wc -l

As to why Firefox uses so many redundant lines in the preference file for settings that have never been changed from the defaults ... well, your guess is as good as mine.

Tags: firefox, mozilla, preferences, printing
[ 19:59 Mar 19, 2010    More tech/web | permalink to this entry | ]

How to print text files in Ubuntu Karmic

Ever since I upgraded to Ubuntu 9.10 "Karmic koala", printing text files has been a problem. They print out with normal line height, but in a super-wide font so I only get about 48 ugly characters per line.

Various people have reported the problem -- for instance, bug 447961 and this post -- but no one seemed to have an answer.

I don't have an answer either, but I do have a workaround. The problem is that Ubuntu is scaling incorrectly. When it thinks it's putting 10 characters per inch (cpi) on a line, it's actually using a font that only fits 6 characters. But if you tell it to fit 17 characters per inch, that comes out pretty close to the 10cpi that's supposed to be the default:

lpr -o cpi=17 filename

As long as you have to specify the cpi, try different settings for it. cpi=20 gives a nice crisp looking font with about 11.8 characters per inch. If needed, you can adjust line spacing with lpi=NN as well.

Update: The ever-vigilant Till Kamppeter has tracked the problem down to the font used by texttopdf for lp/lpr printing. Interesting details in bug 447961.

Tags: printing, ubuntu, linux, tips
[ 16:36 Jan 25, 2010    More linux | permalink to this entry | ]

Fixing holiday photos with GIMP

Third in my GIMP-for-the-holidays series on Linux Planet: Fixing holiday photos with GIMP

Happy holidays, everybody ... and happy holiday photos!

Tags: writing, gimp, printing
[ 19:44 Dec 23, 2009    More gimp | permalink to this entry | ]

Print your custom-made greeting cards

A followup to last week's article on making custom greeting cards with GIMP, today's Linux Planet tutorial discusses how to get those cards printed -- even if you don't own a decent color printer.

On Linux Planet: Printing Holiday Cards Even if you Don't Have a Printer.

Tags: writing, gimp, printing
[ 19:50 Dec 17, 2009    More gimp | permalink to this entry | ]

HP Deskjet F4280

I had been dithering about whether to buy another inkjet to replace the Epson C86 that died earlier this year. The Epson wasn't all that old, but its nozzles wouldn't unclog, and reviews of Epson's latest printers aren't at all complimentary.

HP looked like the best solution, since they're the only printer manufacturer that supports Linux directly. I new wasn't going to buy Canon, because their closed protocols mean that every Linux driver has to be reverse engineered, and I certainly didn't want a Lexmark (see our last experience with Lexmark in Cracking the Lexmark Code).

But which HP? Their array of models is baffling, and no one seems to know the difference between Deskjets, Officejets and Photosmarts, or whether the inks fade, or whether the nozzles are built into the ink cartridges (so a clogged nozzle doesn't mean a dead printer like it does with Epson). And there's no way to get print samples.

So I dithered and stalled -- until Fry's put the HP Deskjet F4280 on sale for $20. The online reviews were fairly positive. And for that price, and with Linux support, how bad could it be?

Answer: not bad at all. It set up pretty easily in CUPS, though the CUPS test page didn't work even after several tries. Fortunately, I don't need to print CUPS test pages. Printing worked fine from GIMP, Firefox and OpenOffice.

The print quality is surprisingly good. (Note: the F4280 is not the same printer as the Photosmart C4280, which caused some confusion at Fry's when I tried to actually buy one). Text and web page on regular paper come out crisp and sharp. "High quality" on good photo paper looks like a photo as long as you don't examine it too closely. It'll be fine for my holiday greeting cards, business cards and most other tasks involving photos. "Photo quality" takes a lot longer, and is indeed better than "High" if you examine it with a loupe. Nobody's going to confuse it with a real photo print under magnification, but it'll look fine on the wall.

Here's the part that impressed me most: it can print all the way to the edge of the paper with no hassle. I could never do that with the C86: though the hardware was supposedly capable of it, the Gutenprint drivers -- the reason I'd been sticking with Epson all those years -- never could handle it (and tended to print yellow smears on the borders if you tried it). Good job, HP!

It's an "All in one" so it has a built-in scanner too (no fax). SANE (on Ubuntu 9.10) doesn't see the scanner, and I haven't tried to track that down since I already have a good scanner. I wouldn't have bought an "all in one" except that dedicated printers are quite a bit more expensive.

Update: it's the usual Ubuntu permissions problem, combined with new udev rules. Root sees the scanner, users don't, unless you add lines to two different udev rules files. In /lib/udev/rules.d/40-libsane.rules, add:
ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="2504", ENV{libsane_matched}="yes"
then create a new file /etc/udev/rules.d/45-libsane.rules and put in it:
SYSFS{idVendor}=="03f0", SYSFS{idProduct}=="2504", MODE="664", GROUP="scanner"
More details are in bug 121082.

And wow, the scanner output is really bad. I mean really, really bad. I'm happy with the printer but I'll definitely keep my old Epson scanner.

Reviews complain that the F4280 is rather ink-hungry and the ink cartridges are overpriced; but every inkjet printer review says that (probably with good reason). I don't print that much, so I'm not too worried. And of course I know nothing about long term reliability or how fade-resistant the prints will be. Ask me in six months. But so far I'm quite pleased. A nice printer with excellent Linux drivers.

Tags: printing, linux
[ 20:47 Dec 05, 2009    More tech | permalink to this entry | ]

Un-Jamming an Epson C86

I turned on my printer to print out a form I needed to mail and it emitted a nasty high-pitched noise ... not quite a squeal, but almost.

And it refused to feed paper more than about an inch at a time. Pressing the paper feed button made it roll the paper about an inch farther down, stop, and squee again. Another press, another inch, stop and squee. Each time it seemed to advance the paper quite smoothly -- it wasn't slipping, jamming or feeding at an angle.

How do you google for a weird high pitched noise? I tried a few phrases in combination with epson c86 OR c84 OR c88 and hit several promising-looking URLs with domain names like fixyourownprinter.com ... but every hit turned out either to be someone describing a problem, then the discussion morphing into a discussion of unclogging ink cartridges, or someone describing a paper feed problem like mine and someone answering with unhelpful advice like "you could fix the mechanism if you could get the back panel off, but that's hard if you're not a printer repair shop and printer repair shops charge more than the printer is worth, so throw it away and buy a new printer."

I try to be green -- I recycle, turn off lights, try to use low power PC and monitor, and I'll be damned if I'm going to throw out a great big hunk of mostly nonrecycleable plastic every couple years without at least trying to fix it.

Giving up on web searching, I unplugged the printer and started pushing and poking at it to see what I could disassemble. The back cover clearly was tucked into the two side covers ... it clearly wasn't going anywhere until those side covers came off.

The side covers had several holes to the plastic piece underneath, with arrows near them seeming to invite "push and slide". But there didn't seem to be much consistency to whether I was supposed to push the outer cover, or the inner tab, in the direction of the arrow. I finally just ignored the arrows and used screwdrivers and pliers to poke and compress and wedge and slide until I got the left side cover (left as seen from the front of the printer) off.

The right side cover was more challenging -- I had all the tabs loose, but the cover seemed to stick at a point near the front, near the "Dura-Brite" oval. After twenty minutes of attempted finesse, I switched to trying to force it (since the alternatives were to throw the printer in the garbage or pay a repair shop more than the price of a new printer). I heard two sharp CRACKs as of plastic tabs breaking ... and the stuck front side popped loose. Curiously, I couldn't find any obviously broken plastic inside; forcing it was apparently the right and only way to get that side cover off.

Inside ... everything in the paper path looked fine. I pulled out an errant paper shard that's been floating in there for about a year (I knew right away when I fed that sheet of business cards with some of the cards already removed that it had been a bad idea) but it hadn't been touching any of the mechanism.

What's this on the left side, though? There was a tiny ink-smudged piece of paper between one of the pulleys and its toothed belt. Hmm. Doesn't look like it ought to be related, but it clearly doesn't belong ... so I pulled it out.

I poked and prodded and shone flashlights for a while longer, but couldn't find anything else. Darn! Well, just for the heck of it, I plugged the printer back in and switched it on. No squee tone! Hmm ... I fed it a piece of scratch paper and pushed the paper feed key ... and the paper went straight through, no noise, no fuss.

Whee! I hooked it up to the computer and tried a nozzle test (escputil -r /dev/usblp0 -mC86 -u -n) and it seems fine! The printer is back in its normal place now ... sans side covers, of course. I figure putting them back on so soon is just an invitation for the problem to come back. I'll put them back on eventually ...

The moral of the story is: don't let ignorance stop you from trying to fix things. Maybe the problem was that little piece of paper wedged in the wheel after all. Or maybe, as I often suspect, sometimes hardware just gets lonely and wants some attention ... and if you're willing to spend an hour dinking with it, it doesn't matter how little you know about what's actually wrong. All it really wanted was your attention.

Tags: hardware, printing, maker
[ 14:12 Sep 13, 2008    More tech | permalink to this entry | ]

Making Firefox default to Portrait printing

I discovered a handy tip for Linux Firefox' printing Page Setup today.

Normal web page printing uses "Portrait" mode: you read the page with the paper oriented so that it's taller than it is wide.

Once a week, I need to print a form from a club web site to bring to the meetings. It's a table that's much wider than it is tall, so I want to print it that way: in "Landscape" mode.

In Firefox 2 (at least on Linux), you can't do that from the Print dialog -- there's no Portrait/Landscape option. So you have to use a separate dialog, Page Setup, following these steps:

1. Run Page Setup
2. Change Portrait to Landscape
3. Click OK
4. Print (bring up the Print dialog and click OK)
5. Run Page Setup
6. Change Landscape to Portrait
7. Click OK

Kind of a lot of steps just to print one landscape page! But if you forget, the next page you print from Firefox will be printed in Landscape mode and will take twice as many pages as it should (if you don't notice what's happening and dive for the printer's OFF switch in time, that being the only way to cancel a printing job once it hits the printer).

This morning, it finally occurred to me that Firefox was storing this setting somehow, most likely in prefs.js. If I could find the setting and force it in user.js (which takes precedence over prefs.js and is not updated by Firefox), I could make Firefox set itself back to Portrait every time it starts up. (prefs.js and user.js are both generally found in $HOME/.mozilla/firefox/).

Some greppery-pokery revealed the solution. I needed only to add a line in user.js that looks like this:

user_pref("print.printer_CUPS/Epson.print_orientation", 0);

and presto! my problem was solved.

Oddly, it's set separately for every printer you have defined, even though there's no way to set one printer to Landscape while another one is still on Portrait (the Page Setup dialog is global, and applies to every printer Firefox knows about). "Epson" is the CUPS name of my primary printer; replace that with your printer's name (as set in CUPS), and add a similar line for each printer you have. For the printers I've used, 0 is Portrait and 1 is Landscape, but you can verify that by typing:

grep orientation prefs.js | grep name

That command will also help you if you're not sure what printers you have defined, or you don't use CUPS but want to try this under a different print spooler. (Don't be misled by all the orientation prefs with "tmp" in the name.)

As a minor digression, there's actually a secret pref that's supposed to give another way around the problem:

user_pref("print.whileInPrintPreview", true);

This lets you do all your printing from the Print Preview window, which offers its own Portrait and Landscape buttons. That would be a nice solution. Alas, the Portrait and Landscape buttons in that dialog currently don't work, and since this preference is undocumented and unmaintained, filing more bugs isn't likely to help.

(I should mention that this all pertains to Firefox 2. I haven't switched to Firefox 3 yet, so I don't know the state of its printing UI, or whether this preference is either helpful or effective there.)

Tags: mozilla, firefox, printing, tips
[ 21:07 Jun 12, 2008    More tech/web | permalink to this entry | ]

The Secret to the CUPS Web Interface

On Dapper, whenever I tried to add a new printer or make any modifications to the existing printer's settings, I would eventually come to a dialog prompting me to enter username and password for 'CUPS'. There seemed to be no right answer: there is no user called "cups" (there's a "cupsys", but that's not what it was asking for), and trying either my own username and password, or root's, just popped up the dialog again. A second attempt always led to a blank white page.

But Carla knew the answer. You're supposed to read:

zless /usr/share/doc/cupsys/README.Debian.gz

then skip to the end of the file where there's a brief hint about this problem, stating that "Administration over the web interface is disabled by default since it requires the CUPS daemon to be able to read /etc/shadow." Note that they don't actually disable it in a way that tells users it's disabled. CUPS apparently doesn't check for read permission on the shadow file before opening it, or check whether there was an error in reading it; it just silently bombs out with no indication what went wrong.

To fix it:

adduser cupsys shadow
adduser yourname lpadmin

You may not need the second line if you're already in group lpadmin (type groups to find out).

Then reboot. (Restarting cups and logging out and back in might be enough: you need to get cups and your login session seeing their new group permissions.)

Now, magically, the CUPS web interface works!

Tags: linux, printing
[ 23:15 Jun 01, 2006    More linux | permalink to this entry | ]

Easy Duplex Printing

Firefox' print system doesn't know how to print just even or just odd pages of a document, so when I need to print out a web page and want it double sided, I've been doing the Duplex Dance: hover over the printer ready to grab each page as it comes out the front so that I can quickly flip it and feed it back into the top of the printer fast enough that the printer doesn't time out with "Out of Paper".

Of course, more often I just sigh and let it print single sided because that's just way too much hassle. But today is Earth Day, so I decided it was time to find a better solution. The solution, obviously, begins with telling the browser to print to a Postscript file. Then the challenge is to find a way to print only the odd pages of the Postscript file, put the pages back in the printer, then print only the even pages.

First I tried to use mpage, which claims to be able to do this. It looked like this command should do it:

mpage -j 1%2 file.ps | lpr

But it didn't work -- it said it was spooling something to the printer, but nothing ever came out. Upon saving the mpage output to a file, I found that gv couldn't show it, citing postscript errors.

But it turns out there's a much easier way: the CUPS lp program has an option called page-set precisely for this purpose, and it's smart about detecting postscript input. This command did the trick:

lp -o page-set=odd file.ps

Then flip the sheets, insert back into the printer, and repeat with even instead of odd. Lovely!

This is documented in http://localhost:631/help/options.html?QUERY=odd#PAGESET -- and the CUPS in-browser help has a search function that took me right to it, I'm happy to note.

Other programs which may to be able to split postscript files into odd and even pages include psselect and perhaps dviduplex.

With a smarter print dialog (one that allowed specifying a custom print command, like Mozilla's used to) you could even define several custom printers, one that printed even pages and one that printed odd. Alas, Firefox' print dialog doesn't allow such things, or even allow defining extra printers. (The Mozilla bug asking for odd/even printing is bug 35228).

From a quick search of about:config, it looks like you might be able to set up something by hand using the print.printer_CUPS/printername.print_command preference (by default mine was set to lpr ${MOZ_PRINTER_NAME:+'-P'}${MOZ_PRINTER_NAME}) but I notice something even more interesting: two variables called print.printer_CUPS/printername.print_evenpages and print.printer_CUPS/printername.print_oddpages (both set to true by default). Also interesting are plex.0.name and plex.count. Might be an easy way to get duplex printing straight from the browser, after doing a little hand-editing to try and persuade Firefox that there's more than one printer. I'll try it next time I need to print something. (It seems wrong to spend Earth Day printing more pages than I actually need.)

Tags: linux, printing
[ 20:21 Apr 23, 2006    More linux | permalink to this entry | ]

Linux Can't Print Envelopes?

I needed to send a formal letter, so I thought, as a nice touch, I'd print the address on the envelope rather than handwriting it.

I felt sure I remembered glabels, that nice, lightweight, straightforward label printing program, having envelope options. But nope, it doesn't have any paper sizes corresponding to envelopes. (It has a size called A10 but it's 1.0236 x 1.4567 inches, not the 4.13 x 9.50 I'd expect for a number-ten envelope.) Darn, that would have been perfect.

OpenOffice doesn't have anything in its templates list that corresponds to an envelope, nor does it have anything in the Wizards list. But googling showed me -- aha! -- that it's hidden in the Insert menu, Insert->envelope -- so if you want to create a new envelope document, create some other type of document first, go to Insert and bring up the envelope dialog, click New to get the envelope, then close the blank dummy document.

But then it doesn't offer a choice of envelope sizes, and puts the text in odd places so you have to fiddle with the margins to get the recipient and return address in normal places. Then, when you go to Preview or Printer Settings, it has forgotten all about the fact that it's doing an envelope and now tries to print in the middle of a sheet of paper. In theory you could fix this by setting the paper size to the size of the envelope -- except that OOo doesn't actually have any envelope sizes in its paper list.

Okay, let's try abiword instead. Abiword has a nice selection of paper sizes, including some common envelope sizes. Choosing A10 envelope and Landscape mode lets me compose a nice looking envelope. But then when I go to Print Preview, it turns out it wants to print it in portrait mode, with the addresses going across the short dimension of the envelope. The Print dialog offers a Paper tab which includes an Orientation dropdown, but changing that from Landscape to Portrait makes no difference: the preview still shows the addresses disappearing off the short dimension of the envelope.

I suppose I should try kword. But it depends on nine other packages, and I was tired of fighting. I gave up and wrote the address out by hand.

The next day, though, I went back to gLabels, poked around for a bit and found out about "Template Designer" (in the File menu). It's almost there ... it's easy to set up custom sizes, but it prints them in the middle of a US-letter page, rather than lined up against the edge of the printer's feeder. I'm dubious that you could feed real envelopes this way with any reliability. Still, it's a lot closer than the word processing programs could get.

Tags: linux, printing
[ 18:36 Mar 18, 2006    More linux | permalink to this entry | ]

Giving Up On Debian -- It Damages My Printer!

I've forever struggled with Debian's printing system. A few months ago, Debian unstable introduced a new package called printconf which, once I discovered by accident it required the parallel port to be in EPP mode, actually detected and configured my trusty Epson Photo 700. It was a happy day!

But since then, the printing system has broken again. It wasn't so bad when printing did nothing at all, or printed random garbage characters or postscript instead of a picture. But now (for the past month or so), what it does is print out a centimeter or so of reasonable graphics, after which the printer starts to issue horrible grinding noises and has to be powered off in order to stop the destruction.

I discovered through much fiddling that I could get the printer working again (on a non-Debian system) by powering it off and leaving it that way for quite a while (a few minutes doesn't seem to be enough, but 20 minutes is), then plugging it into the SuSE 9.1 machine and running a series of clean/nozzle test/clean cycles. Eventually, after the second round where the nozzle test prints clean, the printer works normally again from SuSE or Redhat. I still don't know whether all that loud grinding is doing any permanent damage to the printer.

I suspect the actual problem may be something like paper size. In the few months during which printing actually worked, I had lots of problems with mozilla's printouts overrunning the page, which turned out to be due to Xprint having its own idea of paper size (A4) rather than following the system setting (usletter). I never did find a place to configure Xprint's idea of paper size, so I uninstalled Xprint, and mozilla magically became able to print on usletter paper. But it's possible there are other parameters buried in the debian printing system somewhere, perhaps telling the printer to print to paper wider than it's capable of.

I've filed bugs, but they never get any response which might offer a clue how I could help debug this; I suspect Debian's print spooling system is basically orphaned. I've tried installing and uninstalling every combination of the myriad print spooling components I can find. I'd love to uninstall it all and build the whole spooler from source, and then perhaps try to track down the problem and fix it, but there are so many pieces which all work together in undocumented ways that I don't know where to start. (Perhaps by installing exactly the component set that SuSE does?)

I'm reluctantly giving up on Debian for my primary desktop machine. I like almost everything else about Debian, and I've run it for several years on my primary machine; but during that time I've only had a few months here and there where printing briefly worked before breaking again. There must be a distro that can do easy software updates like Debian, yet is still capable of driving a printer without damaging it!

Tags: linux, debian, printing
[ 23:46 Dec 20, 2004    More linux | permalink to this entry | ]

Little successes (printing on Debian)

Printing's been broken on my Debian machine forever. For one brief shining moment back in July I briefly got it working, then a week later a dist-upgrade broke it again and it's been broken ever since.

Last week Debian Weekly News mentioned a new package called "printconf" which supposedly autoconfigures usb and parallel printers for CUPS. Now, setting aside for the moment that there's already a package called printconf, which configures a completely different spooler than CUPS, and that it's very confusing of Debian to resurrect an old name for a completely different purpose, of course I wanted to try it.

At apt-get time, it asked me whether I wanted to configure my printers now, and of course I said yes. The package installed, it printed a message about restarting CUPS, and no more details. Did it do anything?

I visited the CUPS configuration url (CUPS is configured via a web browser) and the entry looked like my old printer entry. Just for ducks I clicked "print a test page". Nada. So I removed the entry, went back to my root shell and typed printconf. It printed "Restarting cups ... done." No other info. Back to the web configuration page ... no printer there.

Eventually I discovered the -v option, which at least told me that it wasn't finding any parallel printers. I know this printer can be detected via the parallel port (SuSE and Mandrake both autoconfigure it), so something was wrong. Time to look at the BIOS.

A bunch of reboots later, I finally managed to get into my machine's BIOS screen (hint: repeatedly press DEL during boot. The screen saying DEL is the right key only flashes for a fraction of a second, so there's no hope of ever reading it and I wasted several boot cycles pressing function keys instead) and changed the parallel port from "ECP" to "ECP/EPP". Back into Debian -- and voila! printconf saw the printer, autoconfigured it with some magic the earlier entry hadn't had, and after a year and a half I have a debian printer again!

(Incidentally, the parallel port setting isn't why the printer wasn't working before; it was something about the CUPS configuration. Printing used to work on this machine several years ago and the BIOS settings haven't changed since then.)

All hail printconf! I wonder if it's ever occurred to anyone to mention in the man page that it needs an EPP (or ECP/EPP?) parallel port?

Tags: linux, debian, printing
[ 22:05 Nov 05, 2004    More linux | permalink to this entry | ]

gLabels is new and improved

Someone sent me mail asking about my CD label page, and that inspired me to fire up gLabels for the first time in a while. Debian has 1.93.3 (on sarge, anyway) and it's looking very nice! There's now a separate pane for object properties, which I'm not entirely crazy about (takes up a lot of screen space relative to using a dialog) but the most important thing is that the label outlines now draw even if covered by an image. That means that you can reasonably line up a CD label image with the template now, which makes my old patch to gimp-print much less needed.

The gimp-print patch might not be needed at all, if libgnomeprint could print with high quality. I wonder if that's coming? I haven't actually tried printing to see what the quality is like now. I should probably snarf the latest gimp-print and update my patch anyway.

Tags: linux, printing
[ 13:34 Aug 03, 2004    More linux | permalink to this entry | ]

Printing working on debian, at last

After a year of no printing on sid, I went back to sarge to see if I could still print from there.

When I dist-upgraded my ancient sarge, one of the questions it asked me was whether to replace printers.conf. That sounded suspicious: I saved the old printers.conf, then allowed it to replace it with its new version.

Well, sure enough, with the new printers.conf it didn't know about my Epson, and when I went to the cups admin url to add it, there was no "add printer" button. Just like I'd always seen in sid.

In sid, someone once gave me the direct url to "add a printer", but when I followed it, I didn't get a working setup anyway. I decided to try copying my old printers.conf on top of the new one.

And voila, it worked! Printing works okay from sarge. (It still has the problem of the cups test page outlines not aligning well with the physical printer page, so it may not work for printing labels, but it's a start.)

So I moved over to sid, and tried the same printers.conf. Voila, something came out of the printer, the first I've ever seen that happen from sid! It didn't entirely work: I printed a few lines using lpr, and the printer printed those lines but then didn't eject the page, and I had to wrestle with the printer to get the paper out. So all is not quite well in sid land, but it's much farther along than it was using only the tools available in sid (rather than my two-year-old printers.conf originally configured on a much older sarge).

The other interesting file that upgrade asked me about was epson.conf, which turns out to be for the epson scanner, not the epson printer. Perhaps by using that (I saved the old sarge file) I'll eventually be able to get scanning working on sid! That would be lovely. For now, I'm using sarge a lot more.

Tags: linux, debian, printing
[ 23:09 Jul 20, 2004    More linux | permalink to this entry | ]