This PR addresses https://github.com/sul-dlss/content_search/issues/6 in DLSS content_search. The changes eliminate logic that used to handle paged and unpaged objects differently. This seems reasonable because of the use of the construct "image/page [n] of [m]" as a design choice. Canvas labels often don't describe order in any way [cit.], leading to examples such as "page Homily of March of Appendices", which doesn't make much sense.
The Presentation API doesn't provide a way to have a "logical page number" and "digital page (IIIF "Canvas") number or "sequence index" apart from labels, which can have any content whatsoever, so I'm not sure what a better design choice might be here. In the meantime, this uses data that is always available (the number of canvases, regardless of viewingHint) to give an idea of the relative position of the currently focuses canvas in the sequence. I think the spec lacks the data to do better than that for now.
This PR addresses https://github.com/sul-dlss/content_search/issues/6 in DLSS content_search. The changes eliminate logic that used to handle paged and unpaged objects differently. This seems reasonable because of the use of the construct "image/page [n] of [m]" as a design choice. Canvas labels often don't describe order in any way [cit.], leading to examples such as "page Homily of March of Appendices", which doesn't make much sense.
The Presentation API doesn't provide a way to have a "logical page number" and "digital page (IIIF "Canvas") number or "sequence index" apart from labels, which can have any content whatsoever, so I'm not sure what a better design choice might be here. In the meantime, this uses data that is always available (the number of canvases, regardless of viewingHint) to give an idea of the relative position of the currently focuses canvas in the sequence. I think the spec lacks the data to do better than that for now.