XML HOCR/Alto support and alternative Mirador build using the dbmdz overlay work

[DiegoPino]

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

"@id": "https://wellcomelibrary.org/service/alto/b18035723/0?image=0",
  "seeAlso": {
            "@id": "https://wellcomelibrary.org/service/alto/b18035723/0?image=0",
            "format": "text/xml",
            "profile": "http://www.loc.gov/standards/alto/v3/alto.xsd",
            "label": "METS-ALTO XML"
          },

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!

[giancarlobi]

@DiegoPino Great!! I think we need only one between ALTO or hOCR, probably the one nearest to miniOCR data.

[DiegoPino]

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

[DiegoPino]

Updating this @patdunlavey @aksm @alliomeria

Things I learned:

• Webpack. I need to bundle all extra plugins and modules together, similar to this but more advanced (less fixed) https://github.com/ProjectMirador/mirador-plugin-demos/blob/master/src/index.js

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 https://github.com/esmero/format_strawberryfield/blob/37c90b6d042fd0264748a40cf3859bccf5ce6f9a/js/mirador_strawberry.js#L45 because we will expose from our Formatter which plugins will/not be available via our Forms.

To do that, my plan (involves coffee) is to use Webpack Externals: See: https://webpack.js.org/configuration/externals/

Basically I make the bundled JS App depend on a Browser level Javascript variable (in this case our $options config array build by drupal/us shared in the JS above.)

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

See here: https://github.com/ProjectMirador/mirador/blob/86443088714bff0c9d43a3c157e5063644fa624b/webpack.config.js#L26-L46

Thanks!

[jbaiter]

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.

You can simply export a renderMirador function to the global namespace instead! See my SO answer here: https://stackoverflow.com/questions/74076747/mirador-3-setting-different-configuration-options-when-using-build-with-plug-in

This doesn't require any complicated webpack shenanigans and should easily work with an off-the-shelf config. User mel.mason from the IIIF Slack also shared another approach involving separate exports from a bundle, that might be worth a shot as well: https://iiif.slack.com/archives/C148SMLD7/p1666702612871639?thread_ts=1665809331.383149&cid=C148SMLD7

[DiegoPino]

@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!

[DiegoPino]

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...