-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XML HOCR/Alto support and alternative Mirador build using the dbmdz overlay work #128
Comments
@DiegoPino Great!! I think we need only one between ALTO or hOCR, probably the one nearest to miniOCR data. |
Yes! Thanks @giancarlobi ! Ok, we have also a new release here https://github.com/dbmdz/mirador-textoverlay/releases/tag/v0.3.4 Good target to get started. I will check the differences of ALTO v/s hOCR |
Updating this @patdunlavey @aksm @alliomeria Things I learned:
Why more advanced? Because all examples I have seen around showcasing using Mirador with Plugins assume an initial fixed configuration/and initialize of course (bad Mirador) the instance immediately. We need to have control over that and we do not want to initiate Mirador with some fixed/configs, we want to be sure our configs are still coming from here
To do that, my plan (involves coffee) is to use Basically I make the bundled JS App depend on a Browser level Javascript variable (in this case our That is what I have learned so far (gosh). that said I also need to bundle it tighter, Mirador Grows quite big with these dependencies so I might have to see/learn from the base (Mirador Module) web pack bundle generator Thanks! |
You can simply export a This doesn't require any complicated webpack shenanigans and should easily work with an off-the-shelf config. |
@jbaiter this is great, thanks so much. I was going something similar with externals/conditionals but your solution makes totally sense (I have hard time thinking on window/global spaces sometimes, not a JS person clearly). Will also test the me.manson solution. You saved me a few long hours of Webpack Externals and ending with a very Drupal-ly solution. Danke! |
Thanks @jbaiter and @aksm I managed to get a JS exported and working (90%). I have issues (functional ones) with the webpacked JS. It does work, but text-overlay + image-tools don't play together. The moment i pass text-overlay plugin to Mirador (tried with 3.0.0, 3.1.1 and 3.3.0) as a plugin image-tools disappears (no tool bar is rendered at all). Also when I Press on the BLUE + sign on this build I sometimes (many) end with an empty render ... does not happen with the vanilla 3.1.1. I wonder if some "url" or even "@materials-ui" libraries/versions are not matching. I tried to go 1:1 with what Mirador has/plugins have but I have to say (humble) that the level of maintenance between old plugins (image tool is 17 months old) is not 1:1 so hard to track. Will make a commit and leave a public demo somewhere until I figure out what is wrong/why this build is not 1:1 with a vanilla Mirador... |
What is this?
Look kids: https://mirador-textoverlay.netlify.app
And source code https://github.com/dbmdz/mirador-textoverlay
This is a custom Mirador 3 plugin built by Wizard and Techno connoisseur @jbaiter and @dbmdz team that allows selectable and renderable Overlays using IIIF Manifests and the 'seeAlso' key. There is a lot of work behind on making this computable and renderable in real time (a lot of browser debugging). Since we are already enjoying their work (and thankful) and code on HOCR highlighting directly from Solr inside our custom IABookreader extensions I would love to integrate this as a secondary Mirador/Formatter for that use case.
Example from https://wellcomelibrary.org/iiif/b18035723/manifest
What is needed?
We need to add a new dynamic Route/endpoint that can deliver our Solr Stored miniOCR as miniOCR.xml (obvious) but also transform on the fly (blow up) Alto and/or HOCR ? (and we may not need both). miniOCR is not yet supported but we are happy to adapt. This (fun) can either be a Twig template or an actual XSLT. Twig will process faster of course.
Secondly we need to build our own Mirador 3 and add this and hopefully to use the energy a few more Plugins.I wish Plugins where dynamically but we will have to not use CDN for this. I mean eventually, once built, via the GitHub magic to CDN connection we will be able to serve that way.
Adapt our IIIF manifest 3 Metadata Display Entities (Twig) to expose OCR when already present as documented using
"seeAlso"
(or always even if not present yet)-Report back and show @dbmdz our love and implementation.
That should be all. This also means, we need to start injecting (looking at @alliomeria 👀 ) our other WebAnnotations, rectangles and polygons into the manifests.
Thanks!
The text was updated successfully, but these errors were encountered: