search

digicademy / svsal

The School of Salamanca. Web Application
MIT License
16 stars 7 forks source link

Fix "Sync" button in viewer #65

Open awagner-mainz opened 5 years ago

awagner-mainz commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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: https://github.com/digicademy/svsal/blob/c44b4d82ff8c596b2245fea65d5150fcae8f1efe/templates/template_work.html#L733
  2. iiif-in.xql in turn calls iiif.xql/iiif:getPageId: https://github.com/digicademy/svsal/blob/7776af381db11d96c82567d7f5da002964a64563/iiif-in.xql#L19
  3. iiif.xql/iiif:getPageId is meant to return the URI of the html fragment containing the requested canvasId: https://github.com/digicademy/svsal/blob/7776af381db11d96c82567d7f5da002964a64563/modules/iiif.xql#L556
  4. This is then used to construct a URI with fragment (from the json) and viewer parameter to go to: https://github.com/digicademy/svsal/blob/c44b4d82ff8c596b2245fea65d5150fcae8f1efe/templates/template_work.html#L737

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 commented 5 years ago

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 https://github.com/digicademy/svsal/commit/7b99f337a2c2fcdbdc8d16cb00c125341bd4b3fc .

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 commented 5 years ago

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