Both the Adobe Reader and Google Chrome PDF plugins accept several URL parameters which can be defined via the. Adobe has published a short overview on these parameters at.These optional parameters affect the behavior of the PDF plugin in several ways. The two most commonly used parameters - at least from my point of view - are:. page=: PDF is scrolled to the page specified. search=: The search box is populated with the search term and the PDF is searched (text is highlighted, etc.).Both of these parameters seem straightforward to implement and would create compatibility with use cases where these parameters are used in e.g. In third-party web applications.Please note that I have searched the issue list for similiar feature requests and found nothing relevant, this is why I have created this ticket. OK on pdfViewSetHash, thanks.

1. Embed Pdf File In Pdf

Also, the use case needs to specify the nth match.This means we'd only want to highlight and 'jump to' the 3rd or 11th or whatever occurrence of the match.Ideas include:. #search='some phrase',3. #search='some phrase'&searchocc=3I like better.From the docs that linked to:● search=wordList Opens the Search UI and performs a search for the specified word list in the document.

Matching words are highlighted in the document. The words must be enclosed in quotes and separated by spaces; for example:#search=”word1 word2”● Individual parameters, together with their values (separated by & or #), can be nogreater then 32 characters in length.● You cannot use the reserved characters =, #, and &. There is no way to escape thesespecial characters.So it seems like pdf.js find searches for the whole string, while the PDF open parameters seem to suggest it searches on each work.

Embed Pdf File In Pdf

Pdf.js searches on 'inner loop' while PDF open searches for either 'inner' or 'loop'. If I understand this correctly, thoughts on reconciling the behaviors?PS Even in the online demo, sometimes command-F (I'm on a Mac) brings up Chrome's search and not pdf.js'. This means we'd only want to highlight and 'jump to' the 3rd or 11th or whatever occurrence of the match.I'm not finding that in the PDFOpenParameters.pdf.

So let's make it about 'search=' only.So it seems like pdf.js find searches for the whole string, while the PDF open parameters seem to suggest it searches on each work. Pdf.js searches on 'inner loop' while PDF open searches for either 'inner' or 'loop'. If I understand this correctly, thoughts on reconciling the behaviors?Let's implement 'Opens the Search UI and performs a search for the specified word list phrase in the document'.

If needed, we can address rest of it by changing pdf.js search algorithm later. I'm not finding that in the PDFOpenParameters.pdf. So let's make it about 'search=' only.Correct, it's not in the PDFOpenParameters.pdf BUT that's what my client's use-case needs are. I can't really provide them half a solution.

I'm thinking going to go with #searchocc= occurrence-number as it'll probably be ignored by any other PDF Open implementation without breaking #search.Let's implement 'Opens the Search UI and performs a search for the specified word phrase in the document'. If needed, we can address rest of it by changing pdf.js search algorithm later.Cool. Wow, that's fantastic.I guess my only remaining question is this then:- is pdfjs then going to try and conform to the way that Adobe have specified the PDF Open Parameters, in that:would retrieve a list (the search would then be for strings that match 'Trace-based' OR 'compiler')and use some other URL Parameter scheme for an exact string/phrase match, say, for instance, something like:-The reason why I ask this is because if you had a URL like:the results would be dependent on which PDF reader the client was using. Surely it would be preferable to aim for a URL parameter scheme that augments the existing one, not 'breaks' it.

(I use the term 'break' loosely here.because it is open to question whether Adobe or Verity, who they bought up, ever really committed to any sort of real openness or process in specifying the Open PDF Parameters.). I'm trying to use #search in the url but can't get working.

No UI Search is display nor the text is highlighted.That's because this functionality hasn't been implemented in pdf.js. The open PR has a partial implementation of #search=. The reason that this PR hasn't been merge yet, is probably that the way pdf.js implements searching doesn't conform exactly to the Adobe specification. I'll ping one of the developers, to see if can be merged.Tryied #scale='100' and doesn't work either.I can't find #scale= in the specification, but using #zoom= should work once lands.