Feature Request: remove 5-second limit on keeping comments visible


#1

When you put your mouse on a comment, you get 5 seconds before it disappears. Then you have to move your mouse off it and back on to get the comment back. Then you get another 5 seconds.

Would like the comment to stay visible until the mouse moves off it.

Thanks


#2

Fixed by windows system timer, any developer can make it shorter, but no more than 5000 ms

for discussion and workaround see open issue https://github.com/sumatrapdfreader/sumatrapdf/issues/512


#3

Cut and paste to another app is a bogus workaround. The Opera PDF plugin doesn’t close comments after 5 seconds, nor does the Windows PDF Reader, nor does the FoxIt reader.

It seems you decided to label or convert a PDF comment into an “infotip”, and want to blame “commenters [who] insist on abusing the term comment by including an essay…”

Silly. 5 seconds is only enough time to read about 3 sentences. Way too short.

I’m trying to read the comments in ‘Introduction to the Insides of PDF’ by James King of Adobe, and it’s a real hassle.

Sumatra is an excellent reading app, but this is the biggest drawback I’ve seen so far.


#4
  1. Modern browsers use viewer based on PDF.js which is executed by JavaScript engine in a browser. As far as I know it’s limited to PDF standard ver.1.4, and newer PDFs (version up to 2.0 now) may be displayed with errors.
  2. An app called “Windows PDF Reader” in Windows 10 is currently replaced by PDF.js executed in MS Edge browser.
  3. Foxit Reader is as huge as Adobe Reader and possibly more buggy, but you haven’t reported how Adobe Reader works.
  4. Yes, I do blame commenters that haven’t heard about footnotes or other ways to make their work usable. Some people must read such ill-formated pdfs on smartphones and it’s a real PITA.
  5. I cannot see your suggestion how to do it better. Would you be so kind and propose any suitable solution, please? That would be really helpful.

#5

Edge doesn’t use Mozilla’s PDF.js AFAIK.


#6

I didn’t mention Mozilla in this topic, and using PDF.js name might be misleading. To be more accurate I should use long descriptive definition: PDF Reader in Windows 10 uses JavaScript code and Edge libraries (including JS Engine).

MS developers change their mind with any Win 10 build so I don’t know which part of pdf parsing is done by exe/dll files and which part goes through JS code in which Windows build. As we know now, MS devs want to create Chromium-based browser, so it may use Mozilla-founded code or some fork in the future. That way “Windows PDF Reader” name is also misleading - it means nothing without specifying Windows version/build.


#7

When you mentioned PDF.js it was but natural to assume you were referring to Mozilla’s JS-based PDF viewer component with that exact name. Your explanation makes it clear now what you were referring to.

Whether the Windows (Edge) PDF component is a EXE/DLL or JS-based is completely irrelevant to end users who’re simply looking to view their PDFs. All that’s important to note is that according to MS’ specs for Edge it supports ISO 32000-1 (i.e. PDF 1.7) with these exceptions/variations. The limitations of Edge’s annotation support are mentioned here.

Chromium has its own PDF code that’s entirely separate from Mozilla’s. When Chromium-based Edge is released it will no doubt switch to using this code. Also, AFAIK MS plans to contribute patches to Chromium instead of creating an entirely new fork of its own (it is clearly desperate for Chrome compatibility and doesn’t want fragmentation again). This is completely expected given the fact that MS has already been actively contributing to the Chromium codebase to get it to run natively on Win10 for ARM.

P.S. IMO Chromium monoculture is not good for the web in the long run. Unfortunately Mozilla is becoming mostly irrelevant in terms of market share, and if Google stops paying for search integration then ~90% of its revenue will disappear and it will collapse unless someone else saves it.


#8

Thanks for the clarification. Just one question - what PDF version is supported by Chromium?
And totally agree about bad monoculture. People seem to forget about MS abusing IE monopolistic position.


#9

Unfortunately I’ve not been able to locate any firm PDF version support specs when it comes to Chromium’s code. Maybe you will have better luck stepping through their code and docs than I did.


#10

On a very quick filter of that link they are testing many major minor versions but PDF does not seem to be a critical one thus I guess they are accepting 1.0 to 2.0+ it is not so much the version although LaTeX can be very picky about only accepting 1.5 since that was most widely compatable
it is more the extra abusive features that were enhanced from that point onwards