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

format_strawberryfield/js/mirador_strawberry.js

Line 45 in 37c90b6

const miradorInstance = Mirador.viewer($options);

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