Support remote images about browse-ocrd HOT 3 OPEN

we do not differentiate between an OcrdFile's .local_filename (which may be empty) and its .url. The latter could still be downloaded into the document.directory under some name and returned here.

Or perhaps one could somehow make this downloading a lazy operation only to be triggered when actually needed.

BTW, that's also how most OCR-D processors handle this. They rely on Workspace.download_file, which for non-local files will automatically download from the URL and store in the workspace (without actually changing the METS but with a reproducible local path, so subsequent attempts will use the local copy).

from browse-ocrd.

See support_remote_images branch for progress

from browse-ocrd.

One additional feature wish: A graceful way to handle failing downloads, e.g. showing just a placeholder image instead of crashing outright. This does happen in our collection for files in the PRESENTATION fileGrp which references files by file:// URL that are not actually usable outside the network:

<mets:fileGrp USE="PRESENTATION">                                                                                                           
  <mets:file ID="FILE_0001_PRESENTATION" MIMETYPE="image/tiff">                                                                             
    <mets:FLocat xmlns:xlink="http://www.w3.org/1999/xlink" LOCTYPE="URL" xlink:href="file:///goobi/tiff001/sbb/PPN680203753/00000001.tif"/>
  </mets:file>                                                                                                                              

I know that we should fix that on our side but that is not trivial to do and we're probably not the only ones (mis)using mets:FLocat like this.

from browse-ocrd.