Where does the annotator get the IIIF reference to the inscription images?

[geoffroy-noel-ddh]

Hi Simona, I'm copying your question here:

About the images – we found that the error happens when the .jpg images have the value ‘screen’ on @n on the graphic element. This is a mistake, since normally we have ‘screen’ of the .tif images and ‘print’ on the .jpgs. Now that we know this, my question for you is about the annotator’s sensitivity to the markup on the surface element. How does that relate to the IIIF server and is it something to do with how the annotator is parsing the TEI? I don’t know how/why an attribute value in the TEI affects the IIIF server loading the image. Let me know if you have an explanation, it would be useful to know that and see how we can future-proof this.

[geoffroy-noel-ddh]

The reference to the image URL on the IIIF server is constructed by the annotator from the /facsimile/surface/graphic elements. I believe that's the only information at my disposal about the image. The DTS collection doesn't contain references (nor is it supposed to), and the TEI doesn't have anything else about the images.

How does the annotator reconstruct the IIIF URL?

• it takes the @url of all the <graphic n="print"> elements from the TEI
• insert that filename into a URL template to the IIIF server (https://apheleia.classics.ox.ac.uk/iipsrv/iipsrv.fcgi?IIIF=/inscription_images/{DOCID}/{IMGID}_tiled.tif/info.json), which is hard-coded in the annotator code

The passes that to OpenSeaDragon which, in turn passes it to the IIIF server to fetch the tiles.

Why using the "print" urls, rather than the "screen" url?

That's strange indeed. I think it might be an artifact from the time where the IIIF server wasn't available yet and the annotator loaded the .jpg files directly.

I'll try using the screen/tif url instead and test it is it should be the right one.

One issue though for me is that the annotation file name are made from that .jpg. So I'll need to rename all those files.