Printable Version of Topic

Posted by: gjtkb May 29 2021, 11:05 AM

I am writing a search and display interface for our Museum database of historic local newspapers. Each newspaper is/will be filed as a PDF (with imbedded text). I have a database of search terms identifying the appropriate PDF. Given a user-instigated search, I can display a list of PDFs that match the search.
I want to display the PDF navigated to the point where the search term occurs, preferably with controls to move between occurrences of the search term.
I have found that in Firefox, if the link is set to HREF="<url>#search=<searchterm>", it navigates to the first occurrence of <searchterm>, and highlights visible occurrences. This does not work in Chrome.

Is there a better approach? Is there a more portable function than the #search?

Posted by: pandy May 29 2021, 07:11 PM

That has always been glitchy. And there aren't just FF and Chrome you have to deal with. It's just about every PDF reader out there. Not everyone allows documents like PDF to be opened "in the browser".

Posted by: Christian J May 30 2021, 09:42 AM

I don't understand the question:

Do you mean you want to display the contents of several PDFs at once? Or just a list of links to the corresponding PDFs?


But this sounds like a single PDF, which is scrolled down to the first search match.

Browser support aside, I suppose you could theoretically display the contents of several PDFs, with each PDF scrolled down to its first highlighted search match. To make it work in practice, I'd convert the PDF files to HTML first (this can supposedly be done with a PHP library, but I've never tried it).

Posted by: gjtkb May 31 2021, 03:39 AM

At the moment, I can display search results for links. Typically a search will give references for a number of articles, which the user then has to check. Currently, most of the newspapers (back to 1855) are on microfilm, so the check is manual anyway. We are converting the microfilm to PDF; post 2009, the newspapers come as PDF anyway. I want to take advantage of the digitization to take the user straight to the article, rather than have a manual search through a spool of microfilm containing a year's issues. Eventually we will have over 7500 Files for individual issues. Typically a user may get 20-50 hits, can reject a high proportion from the information presented at that stage, and then takes a manageable number on to the article-check.
To clarify about Chrome, the crtl-f and enter the search term works OK on the pdf; it is just that FF allows me to initiate this search in the HREF parameter. To clarify further, this is on an intranet within the Museum at the moment, so I have some control over the browsers used. What I am looking for is a clean process which gets the user to the required article.

Posted by: pandy May 31 2021, 06:09 AM

As I said that PDF feature has always worked inconsistently. Either it works or it doesn't. There is no other way you can implement what you want with PDFs. You have to accept that it will only work for some users and the others at least get the right PDF and can do a manual search themselves.

Posted by: gjtkb Jun 1 2021, 01:41 PM

Thanks for the replies. It helps me clarify the issues, if not reach a technical solution.
In my test rig, the PDFs don't seem to be the core of the problem. Having opened the document (from the database search) I can search for the keyword using ctrl-F and enter the search term, without difficulty.
I can give the users operating instructions to copy the search term into the ctrl-F field, and click until they find the required article.
It would be nice to ensure ctrl-F is automatically invoked, automate the loading of the ctrl-F field, and zoom in on the point of focus (the ctrl-F search hit). I have found in W3schools a javascript to load text (e.g. the search term) onto the clipboard. If I could automatically paste it into the ctrl-F search, I would be most of the way there. I haven't found all of the steps, though.

Posted by: pandy Jun 1 2021, 05:52 PM

I'd say it's the PDF reader that is the issue. And there are quite a few of them around. What's used by FF and Chrome I don't know.