Skip to content
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

Open
DiegoPino opened this issue Feb 18, 2021 · 6 comments
Assignees
Labels
enhancement New feature or request Field Formatter The thing that glues the pieces and adds glitter IIIF Specs/Manifests/Implementations Javascript Favourite language of a PHP developer Twig Twig template processing
Milestone

Comments

@DiegoPino
Copy link
Member

DiegoPino commented Feb 18, 2021

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!

@DiegoPino DiegoPino added enhancement New feature or request Field Formatter The thing that glues the pieces and adds glitter IIIF Specs/Manifests/Implementations Javascript Favourite language of a PHP developer Twig Twig template processing labels Feb 18, 2021
@DiegoPino DiegoPino added this to the 1.1.0 milestone Feb 18, 2021
@giancarlobi
Copy link
Collaborator

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

@DiegoPino
Copy link
Member Author

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
Copy link
Member Author

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

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
Copy link

jbaiter commented Nov 2, 2022

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
Copy link
Member Author

@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
Copy link
Member Author

DiegoPino commented Nov 2, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Field Formatter The thing that glues the pieces and adds glitter IIIF Specs/Manifests/Implementations Javascript Favourite language of a PHP developer Twig Twig template processing
Projects
None yet
Development

No branches or pull requests

4 participants