Sioyek is a PDF viewer with a focus on textbooks and research papers
github.com
github.com
While the keyboard control interface is great the absence of menu commands is not. It's weird to me that there's no way to bring up a help display from within the program (there's one there when you first open, but it vanishes as soon as you open something); I had to go to the website and move to the documentation page to see that I was doing.
Still, it has so many good features built in that are optimized for research that it's worth the inconvenience.
Cahier (https://getcahier.com), the software I'm developing, supports creating cards with references to passages in the PDFs read.
It's exciting to see the developments that are being made in this area in the past few years.
It’s been a few years since I seriously looked at options for my personal use, but I remember being quite disappointed in the options I found. Zotero and org-noter seemed two of the best (though in completely different ways) pieces of software I could find regarding reading or organizing pdfs. I trialed OneNote for a year and liked it in the moment, but zero support for navigation or discovery or review of information make it untenable for building a knowledge base or doing literature review.
I imagine that software which makes reading and connecting document information (in any form: pdf, html, video or other) could be so much better than what I use daily.
2) Document editor apps (Notion, Craft) have popularized the concept of documents as a set of text and non-text blocks. They're useful and provide rich building blocks for documents.
3) Some design engineers are exploring multi-modal text editors. Text, audio and video in the same document, integrated with CRDTs for collaboration.
One would think that digital text editing had already reached state of the art, but the work above shows that there's plenty to discover yet. I'd love to hear your take on what you think could be much better.
(I guess my only concern is around potentially reinventing the wheel when it comes to some of these areas. E.g. do you plan to integrate every feature from Zotero, like the web-integrated grabber? That sounds like a prodigious amount of work, but without it it’s hard to fully supplant Zotero as a reference management solution. I’m curious as to your roadmap for this and what you see as the ultimate feature set and user workflow.)
But we want to expand the supported attachment file formats (possibly with video and audio as well), with full annotation and referencing support, more formatting options in the note editor, .bib import/export, synchronization, linux and mobile apps.
I don't plan on having feature parity with Zotero. I think we can provide more value by focusing on the features that explore the interaction between the annotations and notes and on supporting more media types.
Normally it anchors the annotations for any url but i believe that for PDF is also doing some extra checksum magic to uniquely identify the PDF and apply the annotations.
Furthermore you can have collaboration features such as group annotations. Useful for classes or science labs...
Otherwise, my work of today is lost. What happens if you stop making Cahier someday or if I need to move to another system?
If there's enough interest, I'm also open to documenting the file format we use.
For reference management I'm finally sticking with Zotero after maybe 15 years of trying it. With version 7 beta it's finally becoming really good for my use-cases.
Your note-taking solution seems far superior though. Sometimes I wish we could smash together different software into just the right thing for us.
What other features are essential for you? Do you work on academia or in the industry?
Solid highlighting is important to me. Zotero does it fairly well, but doesn't support freehand highlighting on files that lack OCR.
I've recently gone back to school after a decade in tech.
I use an eink device (kindle scribe) for reading papers as well. Right now, the syncing between this device and the rest of the knowledge base is manual. It'll be perfect to have this also integrated into the workflow smoothly somehow.
Some gripes with this app:
- There's an extension that lets you view PDFs in two columns (panels) side by side. But that literally changes the actual PDF files!
- Plugins are generally challenging to install. I found a workaround and reported it, but IDK if the author took that feedback to improve the app.
- To my knowledge, the app stores its configs in the Applications directory of the app. It'd be nicer to have them in ~/.config.
- The feature to quickly open files in a directory doesn't work for cloud drives (including iCloud).
I really can't remember the name sioyek so I made it an alias to xpdf.
> - There's an extension that lets you view PDFs in two columns (panels) side by side. But that literally changes the actual PDF files!
We have added native two-panel mode in development branch.
> - Plugins are generally challenging to install. I found a workaround and reported it, but IDK if the author took that feedback to improve the app.
In the development branch we have added support for native javascript extensions (with no external dependencies because we use Qt's internal js engine) which should be a lot easier to work with
> - To my knowledge, the app stores its configs in the Applications directory of the app. It'd be nicer to have them in ~/.config.
Also I think in the development branch you can use ~/.config, I am not 100% sure though.
> If set and the file doesn’t have a table of contents, we use heuristic methods to create a table of contents. You can use max_created_toc_size to prevent creating very large table of contents.
https://sioyek-documentation.readthedocs.io/en/latest/config...
For papers or for textbooks I only need a small subset of, I find the autogenerated table of contents + bookmarks is typically sufficient. For other cases I like to use pdf.tocgen (https://github.com/Krasjet/pdf.tocgen) to semi-manually generate a correct table of contents.
Link should be to the website imho.
On the phone, I can use Acrobat Reader and Koreader at the same time.
Other users have noted both of these before. I didn't find an easy fix to 1, and a partial solution to 2 uses an extension, but IIRC it still requires manually running a command to transfer annotations to the PDF document itself.
I consider (2) desirable.
My favorite feature from this program that doesn't exist in any other PDF reader (AFAIK) is visual mark mode, where it highlight each line you read. Very good to reduce eye strain
mupdf -C "#FFFFC0" file.pdf[1] https://www.unicode.org/L2/L2022/22230-math-profile.pdf
[2] https://tex.stackexchange.com/questions/33476/why-cant-fi-be...
It’s definitely worth trying.
PDF reading is the main use I have for a 13 iPad, and I do enough of it that it justifies the device.
If it doesn't, it should be a relatively simple task to upgrade the mupdf library to the latest version and recompile Sioyek to get all the file formats supported by mupdf.
Essentially, as if they had never been written in PDF in the first place. Does anyone know if such a thing exists?
I've seen others propose to replace PDF in favor of more dynamic formats like EPUB. But I wonder if it wouldn't be more pratical to standardize tags and proporties that can be written to the PDFs, so that readers are better able to handle them.
Note: they send your document to the cloud for processing.
Instead of modifying the PDF file (which kind of is against the point of PDF files in the first place, the point is the file looks the same in all devices) we have a ruler which can automatically highlight the line being read. If the line is larger than the window, then we move horizontally so the next part of the line is shown. If the line is such that it is larger than the current window but is smaller than the next horizontal movement, a red notch is displayed in the ruler which marks the location of the line which will be moved to the leftmost side of the window.
I know I explained it poorly, here is a video which should clarify: https://www.youtube.com/watch?v=ZYUYMhvwN3U
I, as a reader, don't care about this. I want the document to be the most readable on all devices.
What PDF readers are people using in their web applications?
Brilliant!
Unrelated to PDF I built a Supernote Obsidian plugin too.
Asking out of curiosity since I've been eyeing eink tablets for a while.
The supernote is light and the right size so reading lying down, at the couch, or sitting on the ground works for me.
https://ewritable.com/best-e-ink-tablets/#Best_Dedicated_Not...
Myself, I just bought the Note Air 3C a few hours ago - I've literally waited a decade for color to show up !
Maybe in yet another decade something GAFAM-free, like PineNote, will be viable, sigh...
There is a reason software must have a clearly defined system requirements.
What's with the attitude? Maybe the author didn't expect people to still be running an OS that's 15 years old and 4 years since its End-Of-Life.
Nothing wrong if you voluntarily choose to daily drive a dead OS today at your own risk, but expecting unpaid developers to cater to your super narrow niche is the epitome of entitlement.
Do you know why the System Requirements pages exist? Do you know who uses them? Do you know what the user does when he opens the System Requirement page and can not find the information whether this or that machine capable of running the software?
> expecting unpaid developers to cater to your super narrow niche is the epitome of entitlement.
Please don't read what I didn't write and have some respect for those who has just unfreezed from a time capsule. Disability to define whether I can run the program even after looking at the System Requirement page is kind of annoying.
"legacy operating systems that have not been supported by their vendor for 4+ years are not supported" is common sense
I have a laptop with ATI videocard, it can not run a modern OS any more.
> is common sense
When the laptop was new, it was a common sense to support as much old Windozes as possible. Come on, this laptop definitely deserves to have a PDF reader.
No it wasn't.
> Come on, this laptop definitely deserves to have a PDF reader.
Then use an operating system that is supported instead of expecting devs to do what you tell them to do.
> No it wasn't.
How old are you? In 2009 it was not just common, backward compability was Windoze's killer feature at that time.
> Then use an operating system that is supported instead of expecting devs to do what you tell them to do.
Adding one text line in System Requirements page, no any coding, is telling devs what to do? There is a reason why the System Requirement pages exist.
You're massively confused and mistaken on what backwards compatibility actually is. Backwards compatibility means that a platform/OS from the present day can run software from the past, not that an OS from the distant past(2009) can somehow magically run software from 15 years in the future, which is what you're trying to do and is not a use case any mainstream OS has ever been designed for since nobody ahs a crystal ball to know how SW will be written in the future.
Implausable. I have a PC from 2006-2007 with a equally old Nvidia card and it can run modern Debian(AntiX 23.1) just fine with FOSS drivers.
>When the laptop was new, it was a common sense to support as much old Windozes as possible.
What does that even mean in correct English without leet speak?
>Come on, this laptop definitely deserves to have a PDF reader.
Instead of expecting people to write Windows 7 compatible software today why aren't you trying Linux on it? Then you can read all the PDFs you like. Have some common sense please.
I expect not this, I expect the author to tell in his minimal requirements page about the OS version.