[Desktop_printing] FW: News From the Field (was: Linux Printing Summit - April 10-12 in Atlanta, GA)

Paul Tykodi ptykodi at tykodi.com
Tue Mar 28 19:18:34 PST 2006

Dear List,

Though I have a varied background in the support of both printers and the
configuration of printing devices on a number of server platforms, I have
the most number of years of experience working with printing issues specific
to the IBM AS/400 – iSeries servers. I e-mailed one of my customers to let
them know I was attending the Linux Printing Summit and to ask whether there
was anything in particular they wanted me to find out for them while I was
at the conference. 

They sent me the following overview of their experience with printing under
Linux to date. All of the information outlined below is related to the first
project they are rolling out using Linux instead of Windows as the client
platform. IBM iSeries Access (mentioned in the posting) is a linux
compatible client side software providing a packaged set of services for
interacting with an IBM AS/400 – iSeries server
(http://www-03.ibm.com/servers/eserver/iseries/access/linux/). The TN5250
package referenced is an open source project hosted on SourceForge

What the user needed to accomplish was to establish a printer session
between a software client running on the Linux host (lp5250d portion of the
TN5250 Open Source Software) and the IBM Server. Once established the
session was used to forward data received on the connection to a physical
printer managed by the typical Linux printing infrastructure.

Where they were kind enough to summarize their experience to date, I thought
that some of their insights might be useful for everyone attending the
upcoming summit to consider.


Best Regards,

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  ptykodi at tykodi.com
WWW:     http://www.tykodi.com

> From: Loye Young 
> Sent: Tuesday, March 28, 2006 5:08 PM
> To: ptykodi at tykodi.com
> Subject: RE: Linux Printing Summit - April 10-12 in Atlanta, GA
> Thanks for your note. I don't have anything in particular for you to ask
> the brain trust, but I can give you a sense of our experience with 
> printing.
> Our experience with printing in Linux has not been horrible if we are
> printing from an OpenSource app to an HP printer, but any deviation from
> the
> well-trod path leaves one mired in the muck. What follows is a summary of
> the problems we've had.
> We finally resolved our issues with setting up the barcode printer, but it
> took literally weeks to figure out. The "complicated" part (the ZPL
> language) was a non-issue because the AS400 already had the necessary
> libraries to translate to ZPL. It was the nitty-gritty of device drivers
> and
> printing daemon configuration that were the problems.
> We essentially had three problems: First, finding the driver for the
> particular printer (Zebra) was difficult. It turns out that CUPS already
> had
> the driver, but it took a long, long time for me to find where. It ended
> up
> that it was listed under a completely different vendor name. Once I found
> the driver, I had to manually edit it to change the specs for the label
> that
> I wanted to print. I'm an obsessive techno-nerd, so I stuck with it until
> I
> figured it out, but I can imagine the frustration a "regular" user would
> have trying to install that printer.
> Second, it was a long, tortuous battle figuring out how to configure the
> lp5250d daemon to talk to the AS400. At first, I tried to use IBM's
> iSeries
> Access program, but it was packaged as an RPM, but I was using the Debian
> distribution. I never could get it to work. I tried converting it with
> alien, I tried manually compiling it, I tried everything I could think of,
> but I couldn't get it to work. So, I used the TN5250 package and
> associated
> lp5250d print daemon. Despite reading the documentation over and over and
> following it precisely (we thought), my colleague and I spent the better
> part of two solid days getting it configured correctly. And the
> documentation we needed wasn't all in one place. We had to piece it all
> together from several disparate sources. None of them were exactly what I
> needed, so I had to piece together bits and pieces of information from
> several documents and use lots of trial and error. One simple question was
> "What if we have two printers on the same box? How do we get the printer
> daemon to print to each." Finally I got it to work, but I spent way too
> much
> time on it. There must be an easier way.
> The third issue we seem to have is with Unix permissions. My users are
> frequently confronted with needing another user's password (often root) to
> restart the printers. The problem also works in reverse: the printer won't
> work, so the user concludes the printer isn't started and fires off the
> printer daemon or attempts to start the printer from the print manager.
> When
> that happens, multiple instances of the daemons will start running in
> memory, but none of them work. The user can kill the daemons running under
> that user's rights, but if it's running under root or under another user's
> rights, I get the call. I then have to log on as root and clean up
> everything. My users shouldn't have to go to that much trouble to make a
> printer work.
> A common theme that runs through these issues is "Reinventing the Wheel".
> I
> know that other people have already figured this stuff out, but it's not
> written down. Even better would be wizards or other scripts that automate
> the process. Whoever wrote the drivers and the daemons knows how to
> configure them, but we users don't. I'm sure it seems self-evident to the
> developers, but it's all Greek to me.
> IMHO, the print device drivers should be abstracted from the user
> experience
> to the greatest extent possible. The user interface should be the same (or
> nearly so) irrespective of the brand and model of the printer. For
> example,
> many options are the same in every printer. Every printer needs to know
> the
> paper size the user wants and whether to print landscape or portrait. The
> print manager should be smart enough to ask the user the right questions
> and
> configure the drivers automatically. The print manager should also handle
> consistently among printers custom paper sizes, how dark to print, and
> other
> custom settings.
> Perhaps my experience is not typical. I was using a specialized barcode
> printer (though it is among the most widely used barcode printers around)
> and printing from the AS400 (though IBM is hardly an unknown vendor). Even
> so, there should be a way to make all the pieces play nicer with each
> other.
> Anything that the folks in Atlanta can do to make the printing process
> smoother would be appreciated.
> [Rant mode = OFF]
> Thanks for thinking of us, and keep in touch. Learn as much as you can at
> the conference, because we may need to call on you again.
> Loye
> PS -- Configuration we are using:
> Distribution: Mepis 3.4 (a Debian distro)
> Debian release: Sarge for servers and Etch for workstations
> Kernel: 2.6.12
> Desktop: KDE (ranging from 3.3 to 3.5, depending on the box)
> Computer: HP box, with Intel P4 processor, 512 memory
> Printer connection: Parallel and USB ports
> Printers: HP LaserJet 3015 (standard printer) and Zebra 105SL (barcode
> printer)

More information about the Printing-summit mailing list