How to print to USB printer from embedded ARM board?

[Lennart Sorensen]

On Sat, Mar 31, 2007 at 03:33:43PM -0400, Kevin Cozens wrote:
> I have been approached about helping on a project that is running Linux on 
> an Embedded ARM board (a TS-7250). The application being run on the board 
> needs to be able use a printer connected via USB. The idea is to not be 
> tied to one specific printer.

Assuming the clients using the printer run windows and will install the
right print driver, then having it setup to use raw mode to the usb
printer could work.  If you want to be able to do anymore or support
clients that use postscript (like many cups clients expect) then I
suspect the general answer is that it can not be done.  Lots of printers
simply have no support under anything other than windows.

> The board comes standard with 32MB SDRAM and 32MB Flash disk and is 
> optionally available with up to 64MB SDRAM and 128MB Flash disk. The board 
> also supports USB Flash drives.

I wouldn't want to run ghostscript or any other rendering application to
drive an inkjet or win printer with that amount of resources.  Yet
another reason to probably just support raw mode.

> I'm going to be checking what is provided with the stock demo Linux distro 
> that comes with the board (TS-Linux) as well as the Debian distro that is 
> also available for the board to see what (if any) printing related packages 
> may already be included in the two distros.
> 
> The easiest way to provide support for printing some text and some line 
> graphs would be for the program to generate Postscript code and pass that 
> to a typical Linux printing system based on lpr (or an lpr variant) or even 
> CUPS along Ghostscript and (possibly) a2ps.
> 
> This brings to mind several questions.
> 
> Does anyone happen to have a general idea how much disk space an Lpr/CUPS 
> with Ghostscript printing system would need? I don't need to support all 
> printers at once. The packages could be stripped down so that only one 
> printer is supported at any given time. Similarly with fonts as only a few 
> of the basic ones would be made available.

You would need temp space for the rendered dumps before they are passed
to the printer.  As for the print system itself, not sure.

> How much memory might be required by the printing process to (mainly for 
> Ghostscript) while generating the data to be sent to the attached printer 
> from the passed Postscript code?

ghostscript can use a lot of ram (certainly more than 64MB) in my
experience.

> Any recommendations as to printing system to use (lpr, GNUlpr, LprNG, cups)?

I wouldn't dream of using anything other than cups anymore.  It supports
IPP and LPD as input protocols as well as IPP, LPD, jetdirect, samba,
and many more as output protocols (although you might only want USB).

> Are there pre-compiled packages of lpr (& c.), Ghostscript, etc. already 
> out there for ARM? (It would save me cross-compiling).

Well debian has arm support, both big endian and little endian for many
arm based devices.

http://www.embeddedarm.com/linux/ARM.htm even mentions debian as an
option for that particular board.  Of course debian could be a bit big
for such a small flash.  256MB is easy to run debian in, but even 128MB
could be rather tight.  It can be shrunk a bit though.

> Are there any other thoughts or concerns I should be considering that I 
> might have overlooked?
> 
> I'm still doing my own investigation regarding the project. I just thought 
> I would tap in to the minds and experiences of the other members of TLUG 
> before I agree to work on the project.

Well I have seen print servers before that supported parallel or usb
devices, and all of them were raw mode only.  They did no rendering or
conversion at all, leaving that to the clients instead since they would
actually have the resources to do the job, and it gives the clients full
support for the features of their printer in the driver they use.

Since you apparently want to support output from an application and not
to be a print server, I think you unfortunately are stuck with only
supporting certain printers which are those with good linux support, and
with low overhead for generating the output.  I would think it might
actually require limiting support to postscript printers to avoid the
rendering overhead that I am not sure you have enough resources to do,
although it would be worth testing.  Certainly hpijs/hplip supports a
lot of modern HP printers, and gutenprint/gimpprint supports a lot of
epson and other inkjet printers as well as some laser printers.

--
Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists