Field guide — the same job, command-oriented

The LFP load file format — IPRO's command grammar

An LFP does the OPT's job in a different grammar: instead of one flat row per page, each line is a command with an operation code.

What it is

LFP is the image load file of the IPRO lineage. It carries the same information as an OPT, but each line begins with a two-letter command rather than being purely positional, and image records share the file with other record types — offline or native-file records, replacement records, issue records. We read the IM image records and keep the rest aside verbatim, reporting what was there rather than discarding it or refusing the file.

An IM record is: the command, the page key, a boundary flag, an offset, and then an @-block that locates the file. The boundary flag is the document structure — D opens a document, C opens a child document (an attachment), and blank or a single space means "another page of the document already open". The @-block is semicolon-separated as @Volume;Directory;File;Type, where the type is a small numeric code for the image kind — 2 for TIFF and 5 for PDF in the volumes we have seen.

IM,ACME0000001,D,0,@VOL001;IMAGES\001;ACME0000001.tif;2,
IM,ACME0000002, ,0,@VOL001;IMAGES\001;ACME0000002.tif;2,
IM,ACME0000003, ,0,@VOL001;IMAGES\001;ACME0000003.tif;2,

There is an older shape in circulation where the path sits inline with a page number instead of a semicolon block, which puts the boundary flag in a different field position. Guessing per line would misread half a file, so the tool decides from the first image record which shape the file uses and stays with it for the rest of the file.

What the checker reports in an LFP

Structure first: a short path block is the finding that matters most, because an LFP line that is missing part of its path specification will still parse as a line and still look plausible in a text editor. The parser marks the row and continues rather than stopping, so a systematic problem across thousands of lines is reported once with the line numbers it started on, not thousands of times.

Encoding is checked before anything else, as on every file: byte-order marks honored, UTF-8 verified rather than assumed, and a file that fails that check read as Windows-1252 and labeled as such. For an image cross-reference this is not cosmetic — the file is mostly paths, and a mis-decoded path is a path that does not resolve.

Counted against the other files

An LFP contributes both document and child records to the cross-file comparison. Load it alongside the DAT and the counts are put side by side: DAT rows, OPT document breaks, LFP document and child records, DII records. A disagreement means at least one file in the volume is describing a different set of documents than the others — most often because the volume was regenerated after one file had already been written, and only some of the files were replaced.

That comparison is the entire reason to load a whole volume at once rather than checking one file at a time. Each file is internally consistent in the common failure case. It is only when they are put next to each other that the disagreement appears.

Why two path shapes exist

LFP files appear with paths written in both of the shapes described above, and which one you get depends on the tool that wrote the volume rather than on anything in the specification. Both are handled, and the shape found is reported rather than silently normalized, because the difference matters if you are going to hand the file on to somebody else's import profile.