The Creation of JLight (Part 1)

In the fall of 2007 I needed a technical project to work on.

Out of the blue a fella called me from across the state - he had a problem.  His customer was a large Indigo printer and occasionally they had overflow work.  He, of course, had an Indigo, but he also had two iGens.  The Indigo was old and slow, but the iGens were new.  Was there a way, he wanted to know, to print the Indigo output on the iGen?

Not understanding I said, "sure, just send the file over to the iGen RIP".

"No, No" he said, "the files are already RIPed print ready JLYT files."

Now I understood.  This was some sort of file image-type format out of the Indigo RIP that went to the actual printing engine.

I said, "I'm not familiar with that format except generally.  I know its some sort of compressed image.  Send one over and I'll see what I can do..."

So he did.

(Some later efforts on this are described in this blog which I started in early 2009 to discuss the details of decoding the high resolution elements of the file.)

The discussion that follows here is based on my original efforts to decrypt this file format.  I did this as a black-box reverse engineering project.  (I had no prior knowledge of how JLYT works and no access to a JLYT implementation - either as a RIP or print consumer.)

First, what is a "black-box" reverse engineering project? From this link:

Black box reverse engineering is closer to the scientific method, only applied to hardware or software:

   1. Gather information and resources, typically by reading any available public documentation.
   2. Form a hypothesis, such as how something is implemented.
   3. Perform experiment and collect data. For software, the "experiment" is typically a test program of some sort.
   4. Analyze data.
   5. Interpret data and draw conclusions.
   6. Repeat 2..5 until the underlying hardware or software is understood.

The J-LAYOUT files, as they are called, is really a series of press-ready images inside of a PDF wrapper.  This was easy enough to tell by simply opening the file and looking at it.  At the surface it has all the common elements of a PDF file: COS objects, XREF, a root, pages, Kids, and so forth.  Being somewhat expert in this it was fairly easy to see this by basically opening the file in an editor.

However, below the PDF /Page level things were a bit different.  Each JLYT page turned out to be a series of PDF streams.  The structure and form of these was much less clear.  I could see, for example, that what appeared to be each page began with a stream prefixed with 'IC96'.

I surmised this to mean "I = Indigo, N.V. - the original maker of the press and file format", "C = compressed - as in compressed image format", and "96 - the year it was created."

The streams appeared to be sequential within a page so it seemed likely that the series of streams together made up the page.  Each stream was only 65,536 bytes in length - which was odd. PDF streams can be much longer.  So I guessed this was some sort of design limitation - Indigo presses had been around since the mid-1990's so a limit like this seemed rational for the computer hardware at the time.

So my next step was to cobble together the series of streams that I thought made up a page, which I did, and placed it into a file imaginatively called "dummy.guts".  This file was in binary format so it was hard to work with.  I then created some tools to dump out the file in various textual forms: binary, decimal, hex and so on so that I could try and discover the structure.

Since I knew the raster size of the page from the PDF structure I started looking around the IC96 portion of the file.  Eventually I deduced this:

typedef struct {
  char iid[4]; // 'I' 'C' '9' '6'
  short int height;
  short int width;
  short int q1;
  short int q2;
  short int q3;
  short int q4;
} IC96T;

Which told me the height and width of the image - not surprisingly, this match the height and width of the page declared in the PDF portion.

The nex step was to figure out what came next...