Reverse Engineer the CAPT code to generate a PDF (also LIPS vs CAPT)

[RWAP]

This is an odd ask (I realise) but we produce an emulator for various printers - converting the captured data into a PDF so that the printer itself can be removed from the equation completely.

I have only just come across the CAPT printer language and wondered if anyone might be interested in writing a routine to convert the captured data stream (in CAPT) to PDF.

Not easy as the raw data from a Windows test page for the LBP-1310 starts:

00000000 CD CA 10 00 00 11 00 01 00 0D 00 00 00 00 00 00
00000010 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00

That does not seem to match any of the data I can see in the code!

[mounaiban]

There's multiple parts to what you're dealing with here: the LBP-1310, LIPS vs CAPT, the idea of a CAPT-to-PDF conversion and the idea of emulating printers...

LBP1310

This device uses a completely different format and protocol, LIPS, according to page 6-4 (PDF p182) the LBP-1310 manual. The LBP-1310 seems to be capable of on-device rasterisation, based on the specs on page 6-3 (PDF p181): it has a highly-generalised PowerPC 603ei CPU, as opposed to a simpler and cheaper microcontroller and DSP combo.

This suggests that LIPS might be like PCL, which contains page layout information as well as printer control commands.

So the good news and bad news: you are pretty much ready to use this printer for work as it is supported by GhostScript (and therefore CUPS), but support for the LBP-1310 is beyond the scope of Captdriver.

I'm not fluent in Japanese, so I may be a little wrong, but that's my best understanding for now. Here's a link to the other manuals for the LBP-1310 on Canon's Japan website: https://canon.jp/support/manual/lasershot/1310

LIPS vs CAPT

The LBP Image Processing System (LIPS) seems to have a larger scope than CAPT; LIPS includes page description language, CAPT doesn't. LIPS is like a Canon proprietary take on PCL, and appears to be comprehensively documented.

Meanwhile, CAPT was designed to increase the efficiency of host-based rasterisation over a network, in anticipation of an industry standard where servers and workstations would prepare the rasters, then pipe the rasters to the devices in a highly-efficient compressed format. It therefore lacked a page description language; CAPT intended to allow users to choose their own raster image processing solution.

The page description features CAPT misses out on were made up for with more advanced device monitoring and automagic configuration.

CAPT-to-PDF

Now we get to a proposed CAPT-to-PDF converter... all you would get from such an endeavour is a PDF that has every page as a single large bitmap. That is because CAPT only handles rasters. 😾

Maybe as a consolation the PDF would contain device status dumps as each page is being printed out?

Emulating Printers

I still think emulating the printers in pursuit of device preservation is worth pursuing, if you are attempting something like a MESS/MAME driver that simulates device responses. It'll take a lot more time than a data format converter though...