sumatrapdf icon indicating copy to clipboard operation
sumatrapdf copied to clipboard

search parameter does not seem to work

Open yitzkatz opened this issue 4 months ago • 7 comments

SumatraPDF version

  • Version [e.g. 3.5.2, pre-release]

Describe the bug sumatrapdf -search "mark" story.pdf does not open the file story.pdf with the text "mark" set as the search field and hence doesnt locate that field

To Reproduce Pick any PDF file and any word that appears in that file

sumatrapdf -search "mark" story.pdf The search box is empty and nothing is highlighted

Expected behavior It should have found that word in the text

File that reproduces the problem Bug occurs with all PDF files I have tried it on

Screenshots If applicable, add screenshots to help explain your problem.

Additional context I am a recent user of sumatrapdf so may have missed some obvious rule .

yitzkatz avatar Sep 13 '25 22:09 yitzkatz

Hmm only pre-release can be changed thus the 1st test I run must be with the current pre-release https://www.sumatrapdfreader.org/prerelease and it works as expected !

Image

GitHubRulesOK avatar Sep 13 '25 23:09 GitHubRulesOK

Not sure how to progress - mine doesn't work I am using v 3.5.2 64bit on Windows 10

Tried on powershell - didn't run

Are you using standard options?

Meanwhile

  1. I have tried numerous times and at one stage it worked after I removed my previous story.pdf from Sumatra's history- but then It failed to find subsequent occurrences of "mark"

  2. After that invoking the program failed - it no long took note of the -search "mark "

  3. Embedding the command in a .bat file failed to do anything. It just returned to DOS

Could you please try it more than once - ie as a new DOS command

Thanks for your help

yitzkatz avatar Sep 14 '25 11:09 yitzkatz

ok windows 10 64 bit downloaded https://www.sumatrapdfreader.org/dl/rel/3.5.2/SumatraPDF-3.5.2-64.zip right click extracted into a folder and checked functional

Image Close and open a cmd to not "Desperately seeking Susan" but the nominal Mark this will prove the command line with any dropped or named file if we use CMD Image

We can see there is a difference the search works in 3.6 and not 3.5 which is why I said I must ONLY test the prerelease as the issue is "fixed"
Image

How to use that in 3.5 is to try add double quotes like here but it only works if SumatraPDF is active beforehand !

start "3.5" "%~dp0SumatraPDF-3.5.2-64.exe" -search "mark" "%~1"
start "3.5" "%~dp0SumatraPDF-3.5.2-64.exe" -search "mark" "%~1"
pause
Image

GitHubRulesOK avatar Sep 14 '25 13:09 GitHubRulesOK

Thanks for comment. I am now very confused. I have tried to follow the advice given and don't always get the same result (i.e. the search work is sometime listed and sometimes not)

My aim was to be able to install a version of sumatraPDF and call it at any point in DOS with a command like sumatrapdf -search mark file-name

Can I trouble you to share with me a) the url to link to, to get a working version and b) the dos command to use that will always fire up the program with search word inserted in the rightful box, the occurrences highlighted - irrespective of what I did in my previous calls of the program

If anyone has the time to explain this to me over the phone, I am happy to call them. I am based in London, UK

Thanks, Mark

yitzkatz avatar Sep 15 '25 21:09 yitzkatz

@yitzkatz Mark the 3.6 PRE RELEASE version fixed a few issues with command line calling due to how command parses "double quoted marks" it can be downloaded from https://www.sumatrapdfreader.org/prerelease However there are still oddities in how windows uses command line structures that can mean some experimentation when writing a set of command line strings and thus may need use of "escape" characters or alternate/multiple quotes. but my test shows 3.6 is better than current 3.5.

The reason is that SumatraPDF works best when called in memory as it reloads itself on first run so that was why I suggested call 3.5 twice as it is the second call is the one that gets respected, since it is activated by the first call and thus more responsive to pass through secondary commands.

GitHubRulesOK avatar Sep 16 '25 00:09 GitHubRulesOK

Regrettably I have decided to shelve this project which is a big pity SumatraPDF would have formed the major component for a new search utility we were building for multiple PDF files

I may revisit it when the software become more stable/predictable

In the meantime - thanks to all

yitzkatz avatar Sep 17 '25 09:09 yitzkatz

@yitzkatz search in PDF is not that easy, without use Acrobat, which has many search features. For example I am personally playing with another pdfium library (program is only 41 KB) which has a 16 MB dependency and the search there is currently not more advanced than SumatraPDF (but highlight all and count are possible, SLOWLY in larger files ). That would not be bettered unless I spend hours (months) developing multilingual regex systems, and even then be no use for some types of PDF because PDF search functions are very much tied to the way Adobe developed it., So for some languages even Acrobat needs extensive support files.

GitHubRulesOK avatar Sep 17 '25 15:09 GitHubRulesOK