Show HN: Sioyek – PDF viewer for reading research papers and technical documents
sioyek.info
sioyek.info
* 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.
One feature request that I would suggest is synctex support. I can see this to be being useful when writing a paper using LaTeX as well.
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.
[this one]: https://www.st.com/resource/en/reference_manual/rm0377-ultra...
[this other one]: https://datasheets.maximintegrated.com/en/ds/MAX77650-MAX776...
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.
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.
Seriously, though - thanks and congrats
// There is a typo on index.html line 177. https://github.com/ahrm/sioyek-website/blob/3d1b6323a687b809...
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 think current search performance is better than other PDF viewers though (sub-second on a 500 page PDF on my 6700K CPU).
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.
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.
When do you expect the Mac/Linux builds to drop? Is there any way to follow your progress / support?
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.
Here is a link to it, I have no affiliations to the application: https://skim-app.sourceforge.io/
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.
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.
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 read research papers on tablets all the time and not one of them seems to be able to show the whole page as large as a piece of letter paper.
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?
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.
Limited, but helpful.
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.
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).
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.
To illustrate, the annotations in an old Okular version looked like this: https://docs.kde.org/stable5/en/okular/okular/annotations.ht... (the yellow note box, the green lines and so on).
There's a small picture at https://okular.kde.org/ too, it shows a newer version.
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.
Edit: typofix
When it comes to my notes, what I read, or when I read it, any kind of cloud component or connection to the internet is a showstopper for me.
> sync hypothesis <-> zotero
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.
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
Really cool software and feature set.