Handle canvases with no images across all views

[jbaiter]

This PR adds support for canvases with no images to all Mirador views (i.e. Gallery, Image, Scroll, Book), as discussed in #577.
That is, for canvases like these:

{
  "@id": "https://api-stg.digitale-sammlungen.de/iiif/presentation/v2/bsb00060192/canvas/453",
  "@type": "sc:Canvas",
  "height": 0,
  "label": "453",
  "images": [],
  "width": 0
}

Mirador will now make this fact clear in the interface:

Previously Mirador would completely break down with manifests like these.

Unfortunately I'm not that good at graphical design, so the placeholder images will probably need some more work :-)

[coveralls]

Coverage decreased (-0.3%) to 61.148% when pulling 16bdcb3 on dbmdz:handle-no-images-on-canvas into b8ff140 on ProjectMirador:2.1.3.

[sdellis]

@jbaiter good progress! Is this work in reference to this issue (still unresolved)? It seems that instead of the symbol, one would likely want to display a message to the user via the "label" metadata, since there could be a variety of reasons a canvas has no sc:painting images. If there is no image and no metadata indicating the purpose, then I wonder why the viewer would render it.

I'm also curious as to whether one can annotate a canvas with no images, which it seems should be supported according to the Presentation 2.1 spec.

[jbaiter]

@jbaiter good progress! Is this work in reference to this issue (still unresolved)? It seems that instead of the symbol, one would likely want to display a message to the user via the "label" metadata, since there could be a variety of reasons a canvas has no sc:painting images. If there is no image and no metadata indicating the purpose, then I wonder why the viewer would render it.

Did not know about this issue, thanks for pointing it out! My changes were primarily driven by some defective objects here at the BSB that we want to serve via IIIF nevertheless. I did not think too deeply about other use cases, but it would definitely be good to display as much information as possible about the blank canvas.

The symbol is only used for the thumbnails and the book- and scroll-views. The reason for this is that we can't completely circumvent OSD (like for the image view) since one of the two pages might still be present. It should be possible to put arbitrary HTML content onto the missing canvas, but tbh, I was too lazy to implement it, since it was not really needed for our use case.

If there is no image and no metadata indicating the purpose, then I wonder why the viewer would render it.

In our case it is to make sure that the reader understands that there is supposed be a page there, but we are unable to serve it. If we just skipped the defective canvas, it would be very confusing.

I'm also curious as to whether one can annotate a canvas with no images, which it seems should be supported according to the Presentation 2.1 spec.

Yes, this works just fine and is actually what our manifests do, I just added the empty array to the description to make it clearer :-) The check in the code is just !canvas.images, so it works with all false-ish values.

[sdellis]

Ok, great! If I understand your use case correctly, you are able to generate canvases in your manifest for each defective image. I imagine you could also generate a label for it to convey the problem to the user? If not, I would definitely chime in on that issue.

Also, I might suggest a question mark (for "unknown" content) rather than the symbol you've chosen, which tends to be more associated with "access denied" or "prohibited" content.

[jbaiter]

Ok, great! If I understand your use case correctly, you are able to generate canvases in your manifest for each defective image. I imagine you could also generate a label for it to convey the problem to the user? If not, I would definitely chime in on that issue.

Agreed, I will use the available labels in addition to the error message.

Also, I might suggest a question mark (for "unknown" content) rather than the symbol you've chosen, which tends to be more associated with "access denied" or "prohibited" content.

That's indeed a better choice :-) I will add both things first thing tomorrow!

[jbaiter]

Took a bit longer, but I replaced the symbol with a simple question mark (and added borders so it is clearer in double-page view) and added support for displaying the canvas label in addition to the error message.

[coveralls]

Coverage decreased (-0.3%) to 61.488% when pulling c25ab80 on dbmdz:handle-no-images-on-canvas into b4248b4 on ProjectMirador:2.1.3.

[coveralls]

Coverage decreased (-0.04%) to 61.744% when pulling c25ab80 on dbmdz:handle-no-images-on-canvas into b4248b4 on ProjectMirador:2.1.3.

[regisrob]

Thanks @jbaiter for this PR, this is very useful for at least two demo use cases involving missing pages inside reconstructed manuscripts, so using empty canvases (see for example these manifests: http://iiif.biblissima.fr/bbmn-1713-t1/manifest.json and http://demos.biblissima-condorcet.fr/iiif/metadata/florus-dispersus/manifest.json).

It seems that your code only handles canvases with empty "images" array. Moreover the sample manifest you gave in the comment above has a width/height equal to 0, which is not a good practice as far as I know (for instance you may have annotations on the canvas, even if it is blank... scholars may have something to say about the lacuna).
See this thread on iiif-discuss: https://groups.google.com/d/msg/iiif-discuss/prR7gH5clEE/Si3ZLFeXAAAJ

[jbaiter]

It seems that your code only handles canvases with empty "images" array.

No, as mentioned before, the code checks for the truthiness of the images property, i.e. it will handle both the case where it's undefined (i.e. non-existant) and an empty array.

Moreover the sample manifest you gave in the comment above has a width/height equal to 0, which is not a good practice as far as I know (for instance you may have annotations on the canvas, even if it is blank... scholars may have something to say about the lacuna).
See this thread on iiif-discuss: https://groups.google.com/d/msg/iiif-discuss/prR7gH5clEE/Si3ZLFeXAAAJ

Thanks for pointing that out! I will fix that in our backend :-)

Also, thanks for the two example manifests, I found a few bugs through them that are now fixed :-)

[coveralls]

Coverage decreased (-0.05%) to 61.741% when pulling 9820fde on dbmdz:handle-no-images-on-canvas into b4248b4 on ProjectMirador:2.1.3.

[regisrob]

ok @jbaiter, this is great! Now it works fine for me with your last two commits, thanks. I will update the placeholder in the fr translations as soon as your PR is merged (but I think I will skip the "Unfortunately" because it is a bit heavy in french)

[coveralls]

Coverage decreased (-0.05%) to 61.741% when pulling a300433 on dbmdz:handle-no-images-on-canvas into 099324d on ProjectMirador:2.1.3.

[coveralls]

Coverage decreased (-0.3%) to 61.207% when pulling 6606667 on dbmdz:handle-no-images-on-canvas into 993b08e on ProjectMirador:2.1.4.

[coveralls]

Coverage decreased (-0.04%) to 61.398% when pulling 5d7d528 on dbmdz:handle-no-images-on-canvas into 327c10e on ProjectMirador:2.1.4.

[coveralls]

Coverage decreased (-0.04%) to 61.398% when pulling efeeb5d on dbmdz:handle-no-images-on-canvas into 4dbee61 on ProjectMirador:2.2.0.

[coveralls]

Coverage decreased (-0.04%) to 61.185% when pulling 7bbe5f3 on dbmdz:handle-no-images-on-canvas into 768b10a on ProjectMirador:2.2.0.

[coveralls]

Changes Unknown when pulling 210b741 on dbmdz:handle-no-images-on-canvas into ** on ProjectMirador:2.2.0**.

[gigamorph]

@jbaiter Just a question. I have a use case where I need to not display the image but do show the annotations on the canvas -- a temporary hack to hide copyrighted images from certain users -- and am wondering if I can free-ride on your enhancement. But your change would disable the display of the annotations too, since you are not instantiating the OpenSeaDragon object, right?

[jbaiter]

But your change would disable the display of the annotations too, since you are not instantiating the OpenSeaDragon object, right?

Unfortunately, yes :/ Though one could probably work around that with some inline SVG-hackery, i.e. put the placeholder text/image into an SVG that gets passed as an image source to OSD. Though I don't know if OSD handles SVGs :-)

[gigamorph]

@jbaiter Regarding "truthiness of the images property", an empty array [] is truthy (will evaluate to true in the if test) although [] == false is true (![] == false is also true).

I think that's why it fails for me when I set images = [] in my manifest?

[jbaiter]

Oh boy, thank you, I had forgotten how utterly bizarre JavaScript's concept of truthy values is....

[aeschylus]

We're starting concerted development on Mirador 3, so PRs to 2.x are going to be closed out. If this is still an important feature or fix, please re-open on the release-2.7 branch when it becomes available.