<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 23, 2016 at 12:23 AM, Hans Hagen <span dir="ltr"><<a href="mailto:pragma@wxs.nl" target="_blank">pragma@wxs.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Patrick,<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br>
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".<br>
</blockquote>
<br></span>
In addition to L's remark ...<br>
<br>
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.<br>
<br>
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:<br>
<br>
- scan requested<br>
  - image objects made (anchored in other backend mechanisms)<br>
  - image scan happens<br>
    - file is looked up based on info stored in object (1)<br>
    - when known type detailed scan happens (2)<br>
    - extended object is available<br>
   - a valid object is required (contains partially parsed image data + properties now)<br>
<br>
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.<br>
<br>
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).<br>
<br>
>From the upcoming 0.89 manual:<br>
<br>
You can use \type {pdf.setignoreunknownimages(1)} (or at the \TEX\ end<br>
the \type {\pdfvariable} \type {ignoreunknownimages}) to get around a<br>
quit when no known image type is found (based on name or preamble).<br>
Beware: this will not catch invalid images and we cannot guarantee side<br>
effects. A zero dimension image is still included when requested. No<br>
special flags are set. A proper workflow will not rely in such a catch<br>
but make sure that images are valid.<br>
<br>
(Fwiw: personally i'd not rely on such a catch in a workflow.)</blockquote><div><br></div><div> </div></div><br clear="all"><div>on trunk now.</div>-- <br><div class="gmail_signature">luigi<br></div>
</div></div>