You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current structure works okay for a list of single images, but is terrible for other content being rendered on the canvas, and especially detail images (which I'm trying to implement in an OSD overlay at the moment)
Given that a single manifest can have multiple sequences across the same (or at least highly overlapping) sets of canvases, my proposal is:
Pass the manifest object around rather than a string to avoid repeated lookups (not totally necessary, but constantly doing $.manifests[manifestId] seems pointless)
Manifest object has a list of sequences which contain only the identities of the canvases in the right order.
Manifest object also has a dictionary of canvasId : canvasObj that can be used to look up the canvases
Each canvas object maintains the information about the resources associated with it, in the same way that imageObj does now, but with all of the available information. Then views can do different things with that same structured information.
Then the views would store their manifest, sequence index and current position. From there, manifest.canvases[manifest.sequences[view.seqidx][view.position]] would return the canvas object, that maintains all the information needed to render it.
In Presentation API 1.1 this will be even more important with the addition of thumbnails, resource level licenses, attribution and other metadata, and so forth.
The text was updated successfully, but these errors were encountered:
Oh, and the manifestsLoader trick of trashing the manifest object and making a very similar looking dictionary ... cute, but will waste many many many developer hours. (count starts at 1.5 so far :P )
Marked: PlzFix
The current structure works okay for a list of single images, but is terrible for other content being rendered on the canvas, and especially detail images (which I'm trying to implement in an OSD overlay at the moment)
Given that a single manifest can have multiple sequences across the same (or at least highly overlapping) sets of canvases, my proposal is:
In Presentation API 1.1 this will be even more important with the addition of thumbnails, resource level licenses, attribution and other metadata, and so forth.
The text was updated successfully, but these errors were encountered: