IPRO's image load file · the same job as an OPT in a different syntax
An LFP does what an OPT does — ties image files to documents — but each line is a command with an operation code rather than a purely positional row. Image records share the file with other record types: offline-file pointers, replacement records, annotations, volume headers.
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
| Position | Value | Meaning |
|---|---|---|
| 1 | IM | Image record — the command |
| 2 | ACME0000001 | Page key (Bates number of the image) |
| 3 | D / C / blank | Boundary flag: D opens a document, C opens a child (attachment), blank/space = another page of the open document |
| 4 | 0 | Offset / box position field (exporter-dependent) |
| 5 | @VOL001;IMAGES\001;ACME0000001.tif;2 | @-block: @Volume;Directory;File;Type — type 2 = TIFF, 5 = PDF |
The boundary flag is the document structure: counting D records gives document counts, C records give attachment/child counts, and those counts are what the Bates checker puts next to DAT rows and OPT Y-flags when auditing a volume cross-file.
Two LFP dialects circulate. The @-block shape above is the common one; an older shape writes the path inline with a page number instead, which shifts the boundary flag into a different field position. Guessing per line misreads half the file, so the correct behavior is to decide the shape from the first image record and stay with it — and report which shape was found rather than silently normalizing, because the difference matters when you hand the file to someone else's import profile.
The exact command set varies by exporter. Alongside IM you will meet records carrying offline-file pointers, text references, annotations and volume headers — commonly written OF, OT, AN, VN and similar two-letter codes. Implementations differ enough that treating non-IM records as metadata to preserve, not parse-and-flatten, is the safe default: a parser that discards them silently drops annotations and offline references the receiving platform may need. A short path block (an IM line missing part of its @-block) still parses as a line and looks plausible in a text editor — it is the finding that matters most, and it should be reported with line numbers, not thousands of individual warnings.
An LFP is mostly paths, so encoding is not cosmetic: a mis-decoded path is a path that does not resolve. Honor BOMs, verify UTF-8 strictly rather than assuming, and fall back to Windows-1252 with a label — the same procedure as the DAT encoding trap. For cross-file QC, load the LFP alongside the DAT: a disagreement in document counts between the two usually means the volume was regenerated after one file was written and only some files were replaced.