On Sat, Jan 23, 2016 at 12:23 AM, Hans Hagen <[email protected]> wrote: > Hi Patrick, > > In practice, identifying all image files formats (tiff, png, pdf...) >>> *should* work with the first 4 bytes of the file (they were designed this >>> way). >>> >> >> I think I'll go that way, but I still wish (feature request) that LuaTeX >> does not fail with a fatal error if an unknown file format is encountered, >> instead it would be nice to have something like "return nil, errormessage". >> > > In addition to L's remark ... > > Concerning img in luatex: when an image is needed (can be a delayed > action) the backend will create objects that keep some states (e.g. > requirements and later identified properties). Then at some point there is > some checking of filename and preamble, then when it's a known format the > datastructures are checked .. at any point luatex can quit on error > (recovering is no option due to the many dependencies or maybe overflows). > For instance changing the error in a warning (i tested it to be sure) > aborts luatex. > > Now, we could reshuffle code of course (and for instance check first) but > then we have a chicken-egg issue: we have callbacks for locating files and > these can decide to choose for instance to report back a jpg instead of a > gif when present. Think of: > > - scan requested > - image objects made (anchored in other backend mechanisms) > - image scan happens > - file is looked up based on info stored in object (1) > - when known type detailed scan happens (2) > - extended object is available > - a valid object is required (contains partially parsed image data + > properties now) > > moving 1 up in the chain could probably work but then we still can't be > too sure about success later on anyway where we still would need to abort > the run. > > Anyway, I made a catch for an unknown type but beware: you need to check > the dimensions (zero) in order to figure out that was ignored. Basically an > image object is still present but with zero dimensions (after all it was > not scanned). > > From the upcoming 0.89 manual: > > You can use \type {pdf.setignoreunknownimages(1)} (or at the \TEX\ end > the \type {\pdfvariable} \type {ignoreunknownimages}) to get around a > quit when no known image type is found (based on name or preamble). > Beware: this will not catch invalid images and we cannot guarantee side > effects. A zero dimension image is still included when requested. No > special flags are set. A proper workflow will not rely in such a catch > but make sure that images are valid. > > (Fwiw: personally i'd not rely on such a catch in a workflow.)
on trunk now. -- luigi
