Fix "Sync" button in viewer

[awagner-mainz]

If someone opens a viewer window, then pages to some other image, then clicking the "Sync" button in the viewer used to scroll the text to the corresponding page break. This seems to be currently broken. I tried it in W0030, W0007 (resulting in a 404 error in both cases) and W0013 (not responding at all to the click on the "Sync" button).

[dvglc]

This is still not fully solved: Loading page anchors in other fragments works, as well as syncing with the very next or previous anchor in the same fragment. However, when trying to sync with a more distant anchor in the same fragment, the reading view keeps jumping back to the origin anchor when the viewer window is closed.

[awagner-mainz]

Maybe this is due to inconsistencies in (derivative) data: What should happen is this:

1. On click of the "sync" button, template_work.html takes over, gets the canvasId of the requested page and if there's no object $("a[data-canvas='" + $canvasId +"']") in the DOM (i.e. the target is far away and we need to load the respective html fragment first), then it loads iiif-in.xql for the requested canvasId:

   svsal/templates/template_work.html

   Line 733 in c44b4d8

   $.getJSON( 'iiif-in.xql?canvasId=' + $canvasId )

2. iiif-in.xql in turn calls iiif.xql/iiif:getPageId:

   svsal/iiif-in.xql

   Line 19 in 7776af3

   return iiif:getPageId($canvasId)

3. iiif.xql/iiif:getPageId is meant to return the URI of the html fragment containing the requested canvasId:

   svsal/modules/iiif.xql

   Line 556 in 7776af3

   declare function iiif:getPageId($canvasId as xs:string*) {

4. This is then used to construct a URI with fragment (from the json) and viewer parameter to go to:

   svsal/templates/template_work.html

   Line 737 in c44b4d8

   window.location.href = realTarget + "?viewer=" + $canvasId;

However, at step 3 it goes wrong: if a json file is requested from, say https://www.c106-211.cloud.gwdg.de/iiif-in.xql?canvasId=https://facs.c106-211.cloud.gwdg.de/iiif/presentation/W0004/canvas/p19 , then this returns:

{
  "https://facs.c106-211.cloud.gwdg.de/iiif/presentation/W0004/canvas/p19" : null
}

As far as iiif-in.xql and template-work.html are concerned, the presumed URI for our fragment hence seems to be "null". And we end up at a URI like https://www.c106-211.cloud.gwdg.de/en/null?viewer=https://facs.c106-211.cloud.gwdg.de/iiif/presentation/W0034/canvas/p19, which results in a 404 error of course.

So the question seems to be: Why does iiif:getPageId not list the actual URI? It looks into collection($config:html-root) and uses the @data-canvas and @data-sal-id of <a> elements. I seem to remember that we had those, but presently I can't seem to find them anywhere. Have we somehow changed how we are using these attributes?

[dvglc]

There already was a null pointer error with iiif-in.xql / iiif:getPageId() due to an incorrect html query ( span[@data-canvas = $id] instead of a[@data-canvas = $id] ). That should have been fixed with 7b99f33 .

I have been able to reproduce the current error, but after generating the iiif manifest for W0004 again, the error seems to be gone:
{ "https://facs.c106-211.cloud.gwdg.de/iiif/presentation/W0004/canvas/p19" : "https://id.c106-211.cloud.gwdg.de/texts/W0004:pFOL10R" }
Perhaps the iiif data were simply missing or not up to date?

[awagner-mainz]

Good, I will try to spend some time testing this on Wednesday...