// Special route for the dynamic collections, search or browse pages.
// This route is not standard.
'set' => [
'type' => \Laminas\Router\Http\Segment::class,
'options' => [
'route' => '[/:version]/set[/:id]',
// Ids are in the query: "?id[]=1&id[]=2", but may be "?id=1,2"
// or in route: "/set/1,2".
'constraints' => [
'version' => '2|3',
// 'id' => '(?:\d+\,?)*',
'id' => '[^\/]*',
],
'defaults' => [
'version' => $version,
'action' => 'list',
],
],
],
I have no idea from there tho. And since my installation isn’t that far, i can’t try it
Please do copy your config if you manage to get it working
Additionnaly, Have you been able to run ExtractOcr correctly ?
I can’t manually upload an xml because the system won’t let me, saying it’s an unsupported type,
I see that a value attache to my pdf media is modified by the content (but the raw content, no xml tags with it) but whe i run the API call, it returns that there is no xml associated
No, we don’t have ExtractOct working yet. We’re getting a routing error when pdf2html attempts to convert the pdf to xml, and our Systems Librarian is exploring the issue.
I assumed the edit to the Iiif Search module was to be made in the admin UI. Your note to look at the config.php file is a good one, though I’m not sure how/where I’d add the code specified in the documentation to the config php file, since the text to add in the documentation doesn’t seem to match anything in the config in terms of content or format. Have you managed to figure out how to add it at line 271?
Hi,
The params may have been changed, but the feature is still available. The search is a service to add inside a manifest, so there is an event and if iiif search is installed and if the item can be searched, the module IiifSearch adds the service to the maniffest.
You need to have last version of IiifSearch and IiifServer, or a version compatible between them. Note that there is a bug in versin 3.3.2.1 that is fixed but i just see that there is no version 3.3.2.2, so it may be the issue.
I’ll publish the alto version in a few days, so version 3.3.3.
Sincerely,
Thanks for chiming in, Daniel. Yes, I’m using version 3.3.2.1 of the iiif Search module, so I’ll be on the lookout for 3.3.3.
To confirm, it’s expected that I’m no longer seeing a search url option in the iiif Server module settings? So if I install 3.3.3 when it’s available, it ought to just work?
I published a new version of IIIF Search that manages Alto natively. Use my repository, it is not yet included upstream. The module IIIF Server has been updated to support alto too, so the viewer can add an extra layer with the text.
Simply attach the alto files to the item. For now, the filename should be the same than the image one (except extension). A future version will use preferably a linked value between the medias. See readme.
Here with Mirador, but i works with Universal Viewer too.
Hi @Daniel_KM – I’ve installed the updated versions of both module (iiif search 3.3.3 and iiif server 3.6.8.3), and since we’re having issues with the ExtractOCR module, I tried to create an alto test file with Tesseract and load it alongside the pdf. I double checked that it’s an alto v3 file, and the universal viewer seems to recognize it and displays the search box, but when I attempt a search for a known string in the document (one that I verified is in the xml file), the search never resolves, the progress indicator just spins endlessly. Any ideas what might be happening here?
When I test with this url, I see that search is working. However, unlike you, I don’t have a search box in Universal Viewer. @Daniel_KM any idea why search box isn’t displaying even though search seems to be working?
That url test had me a little confused, actually. I’m having trouble getting anything but a “controller not found” 404 error, but I assume that has something to do with our URL conventions on this VM. When you use that URL, are you putting an extant item id into it?
I’ve made some progress here, but I’m still stuck. I installed Mirador, which was a little more helpful and verbose, and when I attempt a search, I get an error that says "SyntaxError: Unexpected token ‘<’, "<!DOCTYPE “… is not valid JSON”
I can see the annotations in the Mirador viewer, so I know that the alto xml file is being read, though I’m not getting any movement of the document in the viewer when I click on an annotation.
I think I’ve narrowed my issue down to the URL the iiif Search module is attempting to use. If I look at a manifest, all of the other URLs included in the manifest seem to resolve, but rootURL/iiif-search/itemNumber doesn’t resolve.
I had thought this was maybe a URL rewrite issue, but the other URLs are resolving, so I’m not sure. Any ideas?
For the issue on the doctype, it seems that mirador is confused between xml and json.
This feature is complex, there are many alto variants, various mixed media, iiif options, etc. and the simplest way to check it is to see it in real life. So you can send me the whole manifest and the api item json, here or via a private message. If it is an issue in the module, i’ll fix it.
Did you have any luck sorting out why rootURL/iiif-search/itemNumber doesn’t resolve?
I’m experiencing this and also thought it was a rewrite issue, but because the other URLs are resolving, I’m also not sure that’s the problem.
All URLs in the manifest begin with https except for the one the IIIF search module is trying to use. I’m not sure if it’s possible to correct this within the module or if this is a server-level issue.
