Canon CAPT printers are GDI printers (or winprinters), using a proprietary and undocumented protocol, that I reverse engineered (see Tools and Techniques).
You can download here a driver for Linux.
The driver works (for the moment) ONLY for parallel port printers. It may work also for other CAPT printers. It is NOT for USB printers.
This driver should support both A4 and Letter sized paper, but I only tested it with A4 sized paper.
|
Version |
Date |
File |
Notes |
|
0.1.1 |
September 2007 |
|
|
|
0.1.2 |
January 2008 |
Small update on ubuntu gutsy |
Follow the instructions presented on the README file in the package.
This driver has been reported to work with these kernel versions and distributions:
Kernel 2.6.20 on Ubuntu Feisty
Kernel 2.6.22 on Ubuntu Gutsy
This driver works with these printers:
Canon LBP-800
It should work with other CAPT printers with parallel interface, but it needs to be confirmed.
none known yet
Here is the way I followed to write this driver:
Found the wonderful pages from Rildo Pragana, he gave me the idea and many hints!
Found Nicholas Boichat web pages, with drivers for some other GDI printers.
Installed Windows XP on QEMU emulator, wich is MUCH faster than Bochs. I did a patch on qemu to allow direct parallel port access and logging to stdout.
Print some (many !!!) documents, from simple to complex ones and analyzed the data. That was one of the 2 difficult things, as the protocol, similar to Canon LBP810 USB printer, is encoded twice, to allow to embed the clock in data sent to parallel port. As a side effect, that showed me how poor is parallel capt protocol, in terms of reliability of transmitted data.... Now I can easily understand why the printer with a too long parallel cable started to print garbage.
As Pragana's direct hardware port access required the root privilege to run the driver, I searched for a way do do it with 'parcapt_pc' module that doesn't require to be root, and allow sharing of the peripheral. As a side effect, the 'lp' module doesn't block the driver anymore.
Read MANY cups documentation pages... that was a nightmare ! CUPS is a very good piece of software with one of the poorest documentation I've ever seen.... That was the second really difficult task, and it's not yet completely done (see TODO file)
As CUPS allows to split the driver in FILTER (the 'soft' part of the driver) and BACKEND (the hardware part), I did it, allowing to put some rudimentary sort of printer detection on it. As a side effect, instead of hard coding the printer's port, you must select a cups 'direct' connection from those offered; more on README file.
The source code is GPL'ed and quite extensively commented; the coding style will maybe shock Linux programmers, but I'm used to do it like that since years. Feel free to reformat it with Astyle !
Comments in source code are in Italian language (sorry, too lazy to translate !)
Makefile is quite simple, no autoconf-automake stuffs, I don't
know (yet) how to do; it should work on many distro's, but is tested
only on Ubuntu Feisty. If somebody has knowledge of packaging
(RPM, DEB) and like to provide them, I'll be glad to add them to
downloads.
In source folder are also 2 codeblocks
projects, one for filter and another for backend. Codeblocks is a
really promising cross platform IDE; if you prefere you can build the
driver with it.
See TODO list for missing features; the most
important is maybe detection of hardware failures (paper jam, paper
out, ...), but I couldn't manage to have communication from Backend
to Filter in cups... nor to have some sort of error messages in the
printer panel. Again, if somebody knows how to do it (I lost 2 nights
on it....), I'll be glad to update the sourcecode.
SPECS file
contains some details of protocol; basically are the same of LBP-810,
with some discovery added.
Parallel port encoding is an
interesting "how to embed cheaply a clock on an already
poor protocol" thing; basically is a double XOR between current
data, previous data and a fixed value (0x43). That took me one week
to decode.... And showed me how NOT to do a printer protocol. I think
that sending some 30 KByte chunks of data on a parallel cable with no
handshaking at all, and no checksum/parity at all, is simply the best
way to loose data. If you don't believe it, try with a 3 meters long
parallel cable.... Maybe your printout will win some
abstract-art-image contest.
As a side effect, the protocol (as is)
DON'T allow a 0x43 byte to be sent, as it would result on 2 identical
bytes output to printer, loosing the clock. I guess Canon has some
code seqence to send 0x43 bytes in some crazy fashion, but I (being
again too lazy) simply changed ALL 0x43 bytes in 0x63 before
sending to printer. That is, an extra pixel, but it shouldn't be
noticeable.
Rildo Pragana, for his GDI printer drivers. His articles are really well done and useful.
Nicholas Boichat, who decoded the CAPT protocol of LBP-810 printer, which is identical of LBP-800 one up to the parallel encoding.
My wife Christiane that hasn't still asked for divorce because of nights lost on PC. :-)