Thanks a lot for your effort. Especially the last feature. I had personally made some modifications to mupdf on my machine for doing this, and add annotations using shortcut keys. But MacOS Catalina somehow screwed up my GL, and it renders the page very oddly, so it no longer works. This reader seems great.
This is great! I love the keyboard-based navigation, and the portals are particularly wonderful, almost making me want to turn my documentation monitor back from vertical to horizontal aspect ratio.
A few questions/feature requests/comments: Is there a way to link to a page/mark/bookmark/figure from outside the document? Can we export the marks/bookmarks/document state to a plaintext-compatible file? And please add a dark mode, full-screen white is just painful after a while. Also, I'm not sure I understand the distinction between marks and bookmarks; are marks single-character only? And can you not jump straight to a bookmark, only bringing up and searching the bookmarks context menu?
I'm an electrical engineer, constantly referencing PDF-based datasheets, application notes, whitepapers, and reference manuals like [this one] or [this other one]. They're similar to the more academic papers that this seems to be targeted towards, and suffer from many of the same problems. The current practice in the industry to make effective use of these PDFs is approximately summed up as "just be really smart and keep track of it all in your head." If you're unusually kind to your coworkers, your co-contributors, and (especially) your future self who haven't recently spent the same hours exhaustively reading these documents you'll mention in a comment in your SPI initialization code to "Set bit 13, CRCEN, before turning on bit 6, SPE, see ref manual page 808" or in your schematic that your PCB needs to "Route for additional 4.7 uF point of load capacitance within 25mm/nH/mOhm, see datasheet page 69".
I see that it can be run from the command line with the file name as an argument, but it doesn't respond to anything beyond argv[1], and the whole point is to be to deep-link inside the file. Ideally, I'd love to see a protocol handler like mailto: or winmerge: so that one could embed links inside PDFs. With that, a user looking at a readme document or code comment could jump to "sioyek://../docs/rm0377*.pdf?808gg" or ".pdf?gb=SPI_CR1".
I also see that it seems to store marks and other persistent data in the "test.db" SQLite file, I'd much rather see this as a JSON/XML/plaintext file (or at least exportable as such) so that I can add it to a project version control repository, allowing me to share my state with others and get it back later.
Regarding dark mode, I understand that some figures, background images, watermarks etc. will make this more difficult. But the most common case of black text on a white background is solved for me in the Firefox PDF viewer with a bookmarklet containing `javascript:(function(){viewer.style = 'filter: grayscale(1) invert(1) sepia(1) contrast(75%)';})()`. Foxit likewise has a night mode.
> A few questions/feature requests/comments: Is there a way to link to a page/mark/bookmark/figure from outside the document?
Yes you can (if I understood your question correctly). Press p and then navigate to the target file and then press p again to create a portal from the source PDF to the target PDF. (you can press tab to automatically jump to the target document if you need to)
> Can we export the marks/bookmarks/document state to a plaintext-compatible file?
Currently not but I could add it as it seems that a lot of people are requesting this feature.
> are marks single-character only? And can you not jump straight to a bookmark, only bringing up and searching the bookmarks context menu?
Yes. You are correct. Marks are meant for quick jumps around documents and Bookmarks are meant to be for more persistent situations (for example you can bookmarks an an exercise in a PDF so you can return to it at a later date when you have more time)
> "Set bit 13, CRCEN, before turning on bit 6, SPE, see ref manual page 808" or in your schematic that your PCB needs to "Route for additional 4.7 uF point of load capacitance within 25mm/nH/mOhm, see datasheet page 69".
I think portals are perfect for this use case because, as I said, you can create portals across different documents.
> I think portals are perfect for this use case because, as I said, you can create portals across different documents.
Many of the documents I'm consuming are PDFs, but I'm typically creating documents that are not PDFs like source code, Markdown/HTML, or schematics (the latter may eventually be exported to PDF, so the approach does have some merit). That's why I'd like a portal or bookmark to open/change focus to the app and jump to the target in one click from outside the document.
I really like the idea of building a PDF viewer for research papers.
One feature that I don’t see mentioned that would convince me to use the product is fast search (possibly after some pre computation)
When I’m reading a long technical document I often search for words/phrases to remember the definition
For some reason, this process is very slow for longer documents and take a couple seconds (various depending on pdf viewer
I’ve always wished this was fast. For example, if I’m going to be reading a paper for 1hr I wouldn’t mind if there computer spent the first minute building a data structure to enable faster lookup times
Does anyone know if a current pdf viewer has this feature
I currently don't do any indexing for general search (though I do index the figures, references and equations when the book is first opened). But I do plan to index more things (like the definitions you mentioned) in the future.
I think current search performance is better than other PDF viewers though (sub-second on a 500 page PDF on my 6700K CPU).
> Does anyone know if a current pdf viewer has this feature
If you mean search within a single PDF (not across PDFs), I've found PDF-XChange Editor (made by Tracker Software) to be fast, < 1 s to fully search a 600 page textbook. It also shows little lines in the scrollbar where the results are, like Chrome does.
Thanks! This looks like a really useful contribution to the open community of research tools. One feature which would be a prerequisite for me is a structured export of data I produced through interaction with PDFs.
This is very cool. The two features I hope for are:
1) Annotations. Could be text bubbles in the margins, or perhaps a little glyph I can click on to see/edit the annotation text itself. Annotations should be stored separately in a text-based format to facilitate version control, sharing, and reuse. I want this for reviewing material from others as well as making my own notes (e.g., when working with a datasheet). What I really want is a whole workflow for reviewing, but just text comments would get much of the way there.
2) One column at a time options. Doesn't need to reflow, just needs to present the text in its natural width so as not to require scrolling up and back to navigate a print-oriented two-column layout that makes no sense on-screen. I wouldn't mind having to horizontal-scroll to see full-width figures and footnotes, but I really want to scroll only in one direction to read the text.
Nice, also highlight creation would be a nice feature and command line argument to open a pdf on a specific page. That would allow a more robust pdf notes management.
I was hoping it was going to be a reflowing PDF reader that makes those narrow columns with small text into larger size text easier to read, like arxiv-vanity.com.
There is an open github issue on the linux build. Currently the project builds and works on linux without any issues. The only thing remaining is packaging the executable so that the user doesn't have to manually install all the libraries which is probably very simple but it is taking me a long time because I am a noob when it comes to linux buils :/ .
The Mac version may take longer simply because I don't have access to a mac computer. Though theoretically it should compile on mac right now.
I would like to plug the open source macOS PDF reading/annotations application Skim. It is the most proficient scientific document viewer I have ever used.
You can currently change the background color of the app (not the PDF) in the configuration file. We don't currently have True Dark Mode but it shouldn't be too hard to implement.
I've been using Acrobat on a FireHD tablet with a dark mode plugin. It works quite well. I can't remember the last time I needed to inhibit the plugin to read something.
I tried the Windows download and went through the tutorial. Some feedback:
1. The low latency feels really good. It's snappy.
2. Smart Jump is great. It seems to target the figure caption though, and depending on zoom level / window size might leave most of the figure out of view. To be fair, the figure links that publishers bake into their PDFs often have the same problem.
3. Smart Jump to figures worked reliably in the scientific articles I tried. Smart Jump to bibliography entries and equations did not, although it worked in the tutorial PDF. Journal PDFs have terrible formatting, so this is understandable. One test case I tried was using a wingdings-like font for the citation brackets; what looked like [13] was stored as @13#. So smart jump works best with well-formed PDFs, but well-formed PDFs also usually already have links embedded.
4. The helper window opened behind the main window (for me, anyway), which is a little awkward.
5. As I was reading, I found myself wanting Smart Portals more than Smart Jump. Same automatic cross-reference detection as Smart Jump, but defining a Portal instead of a link.
6. The view in the helper window can't be zoomed or panned, so unless it's kept at the same width as the main window was when the portal was captured, the helper window tends to crop out part of the captured content.
7. The keyboard-centric navigation is well done and a unique selling point. The Windows file picker feels out of place with this though; I'd expect the file picker to work more like the bookmarks list.
8. I found myself liking shift-o more than I thought I would, more than tabs. It would be helpful to be able to clear entries from the previously opened list though; mine is now littered with test files.
I think I would mainly consider Sioyek when reading book-length PDFs, as some books have a lot of distant cross-references and Sioyek's features could save time there. Probably not article-length PDFs since their brevity makes them easy to navigate by default, and they unfortunately tend to break smart jump.
> It seems to target the figure caption though, and depending on zoom level / window size might leave most of the figure out of view.
You are right. It currently does target the caption (specifically the place where the word `Figure' is). Targeting the exact figure is something that I will work on.
> what looked like [13] was stored as @13#.
We probably should support more citation styles. Currently only the bracket style is supported but some papers cite using parentheses or other formats. If brackets being stored as @[NUM]# turns out to be common I could handle that too but I don't know how common it is since I have never seen something like this.
>The helper window opened behind the main window (for me, anyway), which is a little awkward.
You are right, we should fix this ASAP.
>As I was reading, I found myself wanting Smart Portals more than Smart Jump. Same automatic cross-reference detection as Smart Jump, but defining a Portal instead of a link.
There is kind of an smart portal feature in the sense that if you press 'p' and then middle click on something, then sioyek creates a portal from your current location to the location that it would take you if you just middle clicked on the text.
Automatic cross reference detection without user input is something that I have thought about and definitely want to do but the problem is there may be too many false positives, which could make things annoying. For now I think the semi-smart portals are a decent compromise.
>The view in the helper window can't be zoomed or panned, so unless it's kept at the same width as the main window was when the portal was captured, the helper window tends to crop out part of the captured content.
Yes it can. If you want to adjust a portal, press 'P' (that is, shift+p) while the portal is active. This takes you to the location of portal, now you can pan or zoom in and when you are done, press backspace to get to where you were. The portal will be updated with the new zoom/pan.
> I found myself liking shift-o more than I thought I would, more than tabs. It would be helpful to be able to clear entries from the previously opened list though; mine is now littered with test files.
You are right, definitely should add the ability to delete old documents.
> If brackets being stored as @[NUM]# turns out to be common I could handle that too
I was unclear: The PDF's publisher decided to print the character '[' using the character code for '@' and a font choice that made '@' look like '['. The text content in the PDF did not match the displayed content. These kind of bizarre publishing choices make automated processing of research literature pretty frustrating IMO, so if you decide to just handle well-formed PDFs (e.g., LaTeX output) I think that's reasonable.
Re: zoom & pan in the helper window: I meant zoom & pan post-capture, but I can see how re-capturing is a solution. I was resizing both windows a lot while testing so my portal captures were very inconsistent, which probably isn't the intended workflow.
Thanks for working to make reading research and technical documents a better experience.
I bought one but retuned it immediately. The software is just a dumpster fire. Slow, laggy, no sensible options to crop pdfs or research papers. Even the ebook reader is terrible compared with my kobo. I bought a remarkable because, even though the default reader is also pretty terrible (incredibly slow is the main issue) I figured there might be more of a community push to develop a good solution. I’m still waiting though, and basically haven’t switched to e ink for anything except reading novels yet.
Just to add another viewpoint on annotations: I tend to severely edit a PDF while I'm reading it. For example: crop the top and bottom margins off, expand the left and right margins and use them for text boxes with notes to myself, draw on figures, rearrange figures and text (like a collage) so they're in more convenient places, and add color-coded highlights depending on whether the highlighted text is fact, opinion, an open question, etc. I edit the PDF directly so my notes are available even if I have to use another PDF viewer/editor. If I need to preserve the original PDF I archive it separately. I think one of the key advantages of digital medial is that the user can rearrange and edit it to suit their needs (the other advantage being search / automated indexing). Not sure how many people take this approach, and you're of course free to make the feature work however you think best. Just sharing as a counterpoint to the general consensus for a standalone annotation file.
Please consider storing the annotations external to the PDF. For example, Okular wants to save these to the PDF itself. This doesn't work very well with a read-only network drive (read: corporate environment).
Sioyek currently does have a bookmark support which is external to the PDF (you can bookmark locations in PDF file and you can later quickly search in those bookmarks).
But I assume you mean some sort of visual annotation that is drawn on top of the PDF?
One possibility is the "highlighting" that e-readers like the Kobo perform - I've used it for proofreading.
No typing, just selecting a few words or lines. It's all collected in a notes page/doc, you later look at that and hopefully see or remember what was wrong and fix the original.
We do currently have something like this feature. If you select a piece of text and then press the bookmark button, then the bookmark text will be automatically filled with the selected text. Later, the bookmarks can be searched by pressing `gb' (search the bookmarks in the current document) or `gB' (search all the bookmarks).
Not the OP, but a related feature -- I could also see use in tying notes to a document or sentence.
Sometimes I "translate" a difficult passage to something I can understand (on paper I might write this in margins). At other times, I end up accumulating definitions of terms (or letters) while reading a paper. Today I write those on a separate piece of paper so I can have my definitions table viewable at all times. It would be really nice to have that sort of thing stored and available while I'm working my way through a paper (perhaps similar to the portal feature).
Yes, exactly, visual things drawn on top of the PDF.
I mean things like Okular has: highlighting text (like with a yellow highlighter on paper books), freeform draw tool (like scribbling with a pen), adding short text comments and longer notes, etc.
DISCLAIMER: Not saying that Okular is THE reference to follow, I'm pointing it out because I've experience with it, and for example their decision to save annotations into the PDF itself is in my opinion a lousy one. But the idea that one can free-form annotate and add even longer comments to the pages is a great one. The annotations are like scribblings in a book margin, very useful both when studying and when referring [ * ]. And this is something Okular has done much better than e.g. Evince.
[ * ] Of course, one could use a more elaborate tool to keep references, notes and quotes etc., like Zotero.
I assume something like comments in Word, i.e. highlighting a fragment of document and "attaching" to it a piece of text.
Not sure what is the good presentation for it: clicking or hovering, overlaying or pop-up or a separate window...
I suppose to figure the best UX is not trivial, but even mediocre UX would be really great.
And as others say, ideally keep the annotations outside of the document itself.
I find the drawing UX of Okular very lacking - if this application could have a simple, clean annotations interface that produces clean lines with a tablet, this would be huge for me.
Quite a coincidene than this post pops up just as I'm about to find a better way to navigate mountains of papers.
There is a problem in that I use Programmer's Dvorak; + and ` won't get picked up. But at least I can change the configs as I see fit so all is swell. Thanks for sioyek and again the timing on the post
one thing i wish for in a paper reader: hover (or click) on a reference and get a preview of the cite or fig. that way i don't lose my place in what i'm reading before landing on a cite that's just an authors self cite of their 14th paper on the topic.
You can middle click on a reference to quickly go to the reference. You don't lose your place in the document because you can press backspace to get back to where you were (you could also leave a right-click highlight before you click so when you come back you know exactly the line you were reading).
* You can middle click on a reference/figure to go to the reference/figure (even if the PDF doesn't have links)
* You can middle click on a paper name in references to directly search it on google scholar
* Searchable table of contents
* You can mark locations by character symbols (vim style)
Currently only the Windows build is available. Mac and Linux builds coming soon.