SCoA Printers

[ra1nst0rm3d]

When are you going to implement support for SCoA printers?

[mounaiban]

If you are thinking one bit at a time and in terms of binary trees, yes. But if you are reading multiple bits and treating it as a flag, that works in this case but it actually isn't the correct way to read it (even if it is more efficient).

SCoA appears to be a prefix, variable-length code. The funky opcode numbers might be a way of making sure the opcodes are easy to process, without confusing them for another code, when reading one bit at time.

I didn't use the "correct" approach with my SCoA decoder. When decoding, I think the decompressor is supposed to use a function pointer binary tree to switch between decompression operations. Reading one bit at a time, the bits determine how the tree is navigated. I might do that for a C implementation someday...

[mounaiban]

Just when I thought we knew all the opcodes, another new one turns up...

I'll call this one repeat + new_Long, and it looks like 0b101WWWWW 0b01XXXYYY R Z0..Zn Repeat R 0bXXX times, then dump 0bWWWWWYYY uncompressed bytes Z0..Zn

But wait, there's more!

The new_Long and repeat_Long opcodes were in fact:

old + new_Long: 0b101WWWWW 0b11XXXYYY Z0..Zn, 0bYYY bytes from previous line, then 0bWWWWWXXX uncompressed bytes Z0..Zn

old + repeat_Long: 0b101WWWWW 0b10XXXYYY R, 0bYYY bytes from the previous line, then 0bWWWWWXXX repeats of byte R

UPDATE: the SCoA decoder is now pretty much beta-quality AFAIK, I have been able to decompress all of my test samples so far. Check out this commit: mounaiban/studycapt@f49052ead12a4f7cc5331d495f7365c7fc143561.

The SCoA specs on my wiki have also been updated. Hopefully, we have completely charted the SCoA and preserved the specs for future generations, like just in case someone stumbles upon an LBP800 in 2077...

[ValdikSS]

Is anyone still interested in adding LBP-810/1120 support into this driver? @mounaiban, maybe? I have LBP-1120 in good condition which I can share over the network if anyone willing to work on it.

[mounaiban]

Thanks for reaching out @ValdikSS; LBP-810 and 1120 (and possibly LBP3200) support is still part of the master plan, but we're just short on time. I don't know when we will be able to get back onto working on the driver, but in the meantime, I have updated the SCoA Specifications, particularly on the treatment of previous lines, to hopefully be easier to read.

@ra1nst0rm3d has made a fork specially for working on SCoA support. The driver was reportedly able to communicate with the printer, but the output was not correct. Maybe give it a try if you know C programming?

[ValdikSS]

I've ended up writing my own pbmraw → CAPTv1 converter as a replacement for proprietary captfilter. My goal is to run it on ARM single-board computer, while qemu-i386 gave too low performance for captfilter, about a single page in 30 seconds. Big thanks for your specification on the wiki, it helped a lot, but also had to reverse-engineer the binary as well.

By the way, CAPT implementation from Boichat Nicolas produces incorrectly encoded stream (sporadic black lines, also detected by your decoder). Haven't tried @ra1nst0rm3d encoder or lbp800 encoder.

[ValdikSS]

@mounaiban, how could I contact you in private? Your email is hidden in the commits. Please write me at iam@valdikss.org.ru

[ValdikSS]

@mounaiban https://github.com/mounaiban/captdriver/wiki/SPECS:-SCoA-Specifications CopyThenRepeat (0b01YYYXXX C) accepts 2-7 repeats of C, not 1. Otherwise the printout is garbled.

[mounaiban]

@ValdikSS thanks, I've updated the specs. Sorry I haven't had the time to open up an email for inquiries for my projects, but I feel that I have to do pretty soon; there are some issues that aren't really meant to be publicly discussed... :speak_no_evil:

[ValdikSS]

@mounaiban, I'd like to offer paid captdriver improvement for you (or any other developer willing to do that job). I'm making a print server which I want to be the print server with good obsolete hardware support.

[mounaiban]

@ValdikSS to go faster than 30s/page, you might have to encode the page at the rasteriser as the pixels are being output, which means writing a Ghostscript device.

As for payment, I don't feel it's the right time to accept payment or donations as the driver isn't quite consumer-friendly yet. Payments may be accepted in the future as reimbursement for development costs (and toner!), but not before we achieve 100% layout accuracy (enough for cutting and drilling templates) and at least 75% the speed of the Canon drivers.

[ValdikSS]

to go faster than 30s/page

I've switched to box86 for x86 emulation, it's about 4 times faster than qemu, so it's now 6-7 seconds per page on original driver. I've dropped my encoder implementation (although it worked pretty fine).

As for payment, I don't feel it's the right time to accept payment or donations as the driver isn't quite consumer-friendly yet.

I'm not offering a donation, quite the contrary: I'm willing to sponsor the development.

[ValdikSS]

Here is my converter implementation if it of any help. Comes with some comments and headers. It's battle-tested on many documents, but only on A4 format. captfilter.zip

[RWAP]

@ValdikSS to go faster than 30s/page, you might have to encode the page at the rasteriser as the pixels are being output, which means writing a Ghostscript device.

As for payment, I don't feel it's the right time to accept payment or donations as the driver isn't quite consumer-friendly yet. Payments may be accepted in the future as reimbursement for development costs (and toner!), but not before we achieve 100% layout accuracy (enough for cutting and drilling templates) and at least 75% the speed of the Canon drivers.

I am also interested in developing a printer emulation for the Canon CAPT based printers (yes, I am awkward). It works the other way around, so interpreting the data sent to a parallel port (intended for an early Lasershot LBP-1310) and then creates a PDF of the printed page.

Is anyone interested in this type of code - would be a good way of testing the printer driver too

[mounaiban]

@RWAP LBP-1310 uses LIPS, not CAPT. LIPS is supported by GhostScript in most Linux installations. On an up-to-date GNU/Linux system with CUPS+GS, when you type gs --help into your terminal you should see lips2p thru lips4 and lips4v in the list of devices. GS LIPS output is ready for use with the LBP-1310, all you need is a PPD, or IPP adaptor software.

On the other hand, the much smaller LBP-1210 is a CAPT device.

On the topic of CAPT-to-PDF: all you will get is a PDF with a bitmap for every page, because CAPT doesn't have a page description language. Think of CAPT like fax on USB or IP.

Meanwhile, a LIPS-to-PDF routine has more utility, but I don't know any tool that does such a thing. There's a Japanese document for LIPS on the LBP-1310, but I can't read! :see_no_evil:

For details, please check out this discussion on my repo: mounaiban#37