Since Adobe is pushing a more aggressive stance for monetization of Acrobat, I am trying to replace selected PDF workflows with OSS. Here are some of the tools I use.
qpdf
removing passwords, unlocking PDFs, conversion
install in WSL with apt-get install qpdf
remove password with qpdf --decrypt --password="" input.pdf output.pdf
PDF4QT - Open Source PDF Editing
Deleting, Sorting, Extracting Pages
Currently, no choco release available, must be installed manually from PDF4QT/releases
Inkscape, LibreOffice Draw
editing PDFs, adding text
Mupdf
Command line tool and Python package for parsing, filling forms, adding text
SumatraPDF
Viewing of PDFs
pdfplumber
Awesome python package to extract tables from PDFs into data pipelines. Use with Jupyter Lab
FYI, you can use firefox for viewing,signing, and adding text to PDFs.
You can also use it to remove password (just do print to PDF after unlocking it).
I got all excited - then realised "signing" just means inserting a picture. Notably absent are open source tools for digitally signing and verifying PDF's. Apparently pdftk does it in a paid version.
It's funny in a way - in this thread we have people wanting ways to modify a PDF. Yet to me, being any to prove it's not modified (eg, it's statement provably issued by some bank saying they transferred funds to my bank on behalf of person XYZ) is far more important. Instead we have companies offering paid "document signing services" which are built on sand - you can easily forge / modify any signed document they issue.
PDFTK and pdfjam are two other useful command line tools. I use PDFTK for merging PDFs, extracting/deleting/duplicating pages, and decompressing so I can extract and manipulate text/data in raw PDF commands. I use pdfjam for n-up and adjusting page size and margins.
For extracting to tables I've been using http://tabula.technology/ for a couple of years. It seems to do a pretty good job even with some fairly complex tables and I've not had any problems with it.
Actually SumatraPDF is using MuPDF now. But there is some limitation on rendering PDF and eBook files. For example, formatting PDF file or displaying Unicode characters in epub file.
I like k2pdfopt for reformatting pdfs for my e-reader.
I've also used poppler's pdfimages but I'd prefer like something less buggy for my use case; any version I've tried had problem with one pdf made by Adobe InDesign.
Also, tesseract allows creation of a pdf from the images with the embedded OCR text. It is also built in in the k2pdfopt.
Okular is my go-to document reader across operating systems. In addition to PDF, it can open EPub, DjVU, JPEG, PNG, GIF, Tiff, WebP, CBR, CBZ, DVI, XPS, ODT and other formats.
Adobe Acrobat reader installer is also almost a 1 gb download these days. One thing I do find that Acrobat does better is compression. I can usually reduce a PDF down to about 30%-40% of its original size without much loss in quality. I've tried other tools and they haven't worked nearly as well.
It's funny what you are downvoted, but FR8 was way better OCRing Office-printer-scanned documents even against the much later versions of FR, I saw the comparison on the same source documents.
It matches the pdf style/colors to your emacs theme! Sort of like a dark reader for pdfs, but it automatically adjusts to any theme based on some good but likely imperfect heuristics.
> And yet I do know that you can write complex, relatively bug free code without tests, because I did it.
> I do know that you can write complex, relatively bug free code without anyone looking over your code, because I did it.
> If no one uses your app then who cares if it crashes.
> If many people use your app and it crashes, they’ll tell you and then you’ll fix it.
Those four statements are contradictory. What they're saying is not that you don't need testing or code reviews, but that you can get your users to test for you.
I figure the author probably does test their code (everybody tests, even if that just means running the app), but not rigorously or in a way that you could say gives one the security of regression tests.
No-one worth discussing the issue with claims that it's impossible to write complex code without automated testing. I'm a huge proponent of automated testing, and I wrote a relatively large, cross-platform renderer without a single automated test back in the late 90s/early 00s ... it just took a long time, and I became increasingly terrified of making changes.
What I was trying to say is: there's dogma about tests and code reviews.
At Google you would get fired for suggesting skipping code review.
Even at smaller Silicon Valley companies (smaller == less than 10 devs) it's unthinkable to not do code reviews. I haven't worked outside SV so it might be different.
That's the dogma.
My point is that maybe we should apply a bit of common sense on top of that.
I'm not saying Google should stop doing code reviews - the cost (to Google) of google search breaking is so high that you do 100x more than just code reviews.
But maybe those smaller companies don't need to dogmatically review the checkin for a documentation fix.
The problem with tests is the TDD dogma, which wastes time and makes code harder to change (because even reasonable changes break a bunch of tests).
There's a good rule of testing top level behaviors described in this talk [1]
For code reviews, it's about knowledge handoff. No one disputes you can write great code alone. The problem is that singular geniuses writing functional but unmaintainable code only they understand and then getting hit by a bus or changing jobs is a real issue.
I work in Health IT here in Germany and for the past 3 years we've been "testing" those "smaller companies" for different parts of our business.
It's a mess. We've been paying them serious money for a product. We've never been warned that their product isn't finished yet or that we're the beta testers for the product they'll sell to other clients. Or that we have to invest our own personal and their time to fix their problems and talk to their useless support.
This has become a pattern and I'm done with it. We are slowly moving back to older and larger companies who actually do their work properly before they roll out products and updates.
What "older and larger" company do you have in mind? What ever you do, never choose CGM! They wouldn't even be able to spell "test" if their live depended on it! Nothing new ever works, like at all. Everything older needs at least one or two server restarts a day!
I know CGM from medico...their KIS is a nightmare. We have to communicate with it in hospitals. What an ugly monster and somehow no hospital IT is able to admin it properly.
Wow, didn't expect to see medavis mentioned here on HN. I'm currently writing Data Warehouse software (and more) interfacing with their RIS. However, I don't really know what their testing practices are.
Interesting! From where I'm sitting DoctoLib seems to win over the market.
The DWH software writes snapshots of db_direct into a temporal DB (implemented in Postgres using multiranges) and then uses dbt to transform the data into usable tables. Right now, I use Power BI for visualisation and reporting.
However it's good for usual Doctors offices. It's terrible for Radiology Planning. Also many institutions just put a link to their homepage or phone number in there. This way they're on DL but don't have to deal with the calendar.
> My point is that maybe we should apply a bit of common sense on top of that.
...
> But maybe those smaller companies don't need to dogmatically review the checkin for a documentation fix.
It's not dogma, it's just the necessities of large groups of people working together. A small organization can use common sense, a function that scales up to (20? 50?). 10,000 people can't operate on common sense; they need another function: rules.
Now I'm ready for massive downvotes here but hear me out.
Much of our professional habits are part of the corporate chains which is optimised to deliver and squeeze as much as possible.
Software developed in the wild does not have those corporate obligations and the sole purpose is to enjoy the process, the sheer joy of creating something. Of programming as a creative medium.
You don't get your paintings code reviewed. It's just that artistry. You like it, then you like it, end of the story, you're not playing for the gallery.
Corporate enslavement works differently. It has moved and distributed the part of the factory shift in charge to the dude sitting next to you, cleverly. Many are just complaining to make sure they're considered the quality sensitive cooperate loyals.
You two might like different pigments for the grass and he'll strike down your painting with a red ballpoint if not to his taste.
Happens to all of us and if not, wait for it.
Declaring a single boolean flag in a corporate environment might cost more then an hour to get to a consensus because one I-am-dffierent-I-care-too-much guy has some objection about some ambiguity in the flag name in some far future and has now swayed roughly half the team on his side.
That doesn't exist in open source. Open source is all about anti status quo. It is pure rebillion. It started that way, it is about hippies and naysayers. The very root of the GNU toolchain, Herd etc are probably there.
EDIT: Typos + corporate software development environment.
I'm with the author (op) on this, unless it's critical code, launching a buggy project that gets some use & feedback is way better than holding-on for perfection and face certain project failure.
seek forgiveness rather than permission - gets you launched - gets you better
Agreed that types are better, but good test suites contain plenty of reminders of corner cases that you probably forgot to consider during your refactor.
The reason I never had to install Adobe Reader for more than a decade now is that Sumatra was/is such a tiny install. Thanks!
Edit:
I just checked and Acrobat Reader requires 450/900/380 MB for Win32/Win64/Mac respectively [1]. One might argue that it does more than just read PDFs. But in many cases, reading PDFs is all that I need.
If you are counting MBs at that order, then wxWidgets would be the best option. It can be statically linked easily. The size overhead is about 2.5-3 MB. It is a thin wrapper on top of native controls, so e.g. you can always get to the underlying HWND on Windows. Even for the Windows only app, I'd still pick it due to the sane API.
What does "Qt is bloated" even mean. It's a big framework, split into separate libraries, you include only what you use. Qt is free (most parts are LGPL) and is developed by 100+ professional developers. The quality of the implementations, API and documentation is very very good.
Discarding it out of hand by "qt is bloated" just feels disingenuous to me. You can add to that the fact that qml on the desktop if finally maturing into a viable alternative for widgets, and UI development with qml is such a breath of fresh air.
From a user perspective I remember that being a big thing some time ago when people didn't have anything already using Qt installed did an “apt install” or “yum install” on something that did and saw the small tool they were wanting was going to drag half a desktop environment in with it as dependencies. The same could likely be said for GTK in reverse, I'm not sure what their relative sizes for similar features are these days.
Some use bloated to mean the memory footprint. IIRC GTK has more of a reputation for eating RAM than Qt, but again maybe people notice a single Qt app using a lot of resource (that would be shared if running multiple apps against the same libs) when it is the only one they run.
As you suggest, just stating that “<whatever> is bloated” without reference to some details of what is meant by that, sounds a bit like someone parroting old information and/or group-think rather than having looked into it recently.
Having said that the author has a minimal dependency stance in order to try to maintain a small footprint for the app (“I avoid unnecessary abstractions.” in the section about keeping things small) so any framework that isn't little more than a cosmetic wrapper could legitimately be called more bloated than using nothing at all and talking more directly to the standard OS libs. Also in context (discussing why the product is not cross-platform and is never likely to be) this is not the only reason being given and probably not the most significant one (there may be significant selection of cross-platform issues beyond the UI framework).
The key to a lot of what is in that document is the “It’s my project and I act like it” part. All too often we forget this very important side of things, especially with one-man or small-team projects, and people comment on project decisions as if using the product gives some automatic expectation that the creator will mould it around the needs/wants of a given user or someone's idea of “the community”. For an open source project the community has the option of forking the project or offering to fund the changes they want that aren't otherwise on the creator's roadmap (though obviously the larger the project, the less practical these options may be)…
Sumatra is know for being small, with the portable version currently being 15.3 MiB. QtCore and QtGui together is some 11 MiB (checking the DLLs used by KDE programs on Windows), so those alone would increase the size significantly.
Flutter is decent, most of the browser/Skia based UI kits are more consistent and made by people who have an appreciation for design and aesthetics. But I think Sumatra predates most, if not all of them.
Sure, but not accessibility or UX design. There's more to a good UI than looking pleasant. Far more. I wish we hadn't unlearned that in the past decade, because Flutter and browser-based UI kits throw all of that out the window.
Honestly, this is a guy who uses GDI, so most of the above options will feel bloated already when looking at the source tarball sizes.
That said, has there been any fundamentally groundbreaking crossplatform classic UI toolkits released since the 90s? (IMGui is the only one that has seemed interesting but that's specialized and not a general one really)
There are plethora of cross-platform UI toolkit, each have their own philosophy. IMO, current popular toolkit have declarative aspect in it. Believe or not the most mature UI toolkit is the one built for chromium. It just works everywhere.
EDIT: Another commenter suggest only office as example. IIRC, they are building it using chromium as front-end and .NET as backend.
I think that's the sticking point, declarative toolkits didn't mesh too well with C++(or C) projects so we have a bunch in Rust but that's not too interesting for those with existing codebases, I started on a C++ 20 prototype myself a few years back (because to make it even remotely elegant I felt that I wanted designated initializers from C++20) but it kinda turned into a huge hairball of templates to even approach something like react style jsx/tsx rendering.
I'm pretty sure that something based on IMGui could be more or less isomorphous to React style rendering, it'd be up to someone to implement it though (and it'd probably be worth it since building applications at scale you win back a lot of time by not fiddling with state manually all over the place).
Using Chromium however is explicitly not where we should want to go (it's basically a kitchen sink in itself), but we go there anyhow (me included often) because it's just so much more quick thanks to progress in dev experience in the webdev area.
Interesting read. I was very surprised by the mention of adding editing features at the end. That sounds like a proverbial black hole of potential feature requests and "bloat".
I implore all developers of PDF readers to implement sioyek's overview feature[0]. When you hover on a cross-referenced entry, it opens a little preview window with the contents of the reference. It is an absolute game-changer for reading textbooks and technical papers; I cannot overstate its utility.
I don't believe it's a risk, since you're not injecting arbitrary remote code into a document, you're more overlaying on top of it. Even if the reader wants to execute code, then it will, that's how you have a reader to begin with. As long as it's not the PDF itself (source document) deciding to execute inline code, you should be fine.
What does it matter if it's displayed in the document or in an overlay window or if it's saved in the document or not? That code could try to do anything; many PDF readers have a security option to prevent opening any remote documents or links.
Why do you think there is remote code execution? Without being familiar with that code (or evince code, which does the same thing) I can almost guarantee there is no such thing (what even would they be executing and why?).
How is the remote reference rendered, other than by executing a renderer for that format in a window? Renderers for web pages, for example, are very powerful platforms with a long history of security issues.
I think you've misunderstood the feature. It shows an overlay window of another part of the same PDF you're already in. It doesn't open another PDF or a website or anything, it's just a small preview of another page essentially. You could just as easily scroll to where the reference is placed in the PDF, but this lets you quickly preview the section without actually leaving your position in the document.
Wow, I just installed this for the first time and its performance blows both Adobe Reader (not an achievement) and Foxit (something of an achievement) out of the water! Nice work by these devs. And its install footprint is around 10% of those programs.
What the hell is Adobe doing, I wonder, that makes their software so unbearably slow and painful to use?
Probably supporting 100% of the PDF spec. plus addressing all those obscure feature requests that 6 companies in this one very niche industry really really need. Sumatra is fantastic and basically the only PDF reader I use on Windows, but it does have maybe 10% of the features Adobe acrobat has. It is however the 10% that that basically everybody needs.
I agree that Adobe has more features than SumatraPDF.
Not necessarily the PDF spec itself - SumatraPDF displays pretty much any PDF you throw at it, just way more options and stuff.
And it's not exactly slow. I'm sure the core rendering of PDF pages is same or faster.
It's just slow to start. Like very, very, sluggish slow. And it's very visible to users.
I don't think it's the features that cause the slow startup. They just don't seem to care about optimizing it.
Chrome has more features that Adobe Reader. It has video calling, a capable PDF viewer and all the other stuff in ever growing web standards.
And yet it starts up fast. Not instant as SumatraPDF but way, way faster than Adobe Reader.
I think that it's more than fair benchmark regarding complexity of the app.
The difference is that Chrome team cares about performance, including startup speed, and they spend a lot of resources on it.
I remember Chrome was counting and removing C++ static initializers from their code (the code that runs before main()) because that contributes to startup speed.
That's the level of care you need to have and I think Adobe just doesn't have it.
I understood "pretty much" as "most" but not "all". I've been viewing PDFs for 20+ years and never encountered one with 3D content so ”pretty much” seems like a good adjective to use here for me.
> SumatraPDF displays pretty much any PDF you throw at it
I often use PDF applications for documents that I want to keep for decades, including annotations I make. How much can I count on SumatraPDF, or any PDF application, outputting future compatible documents from conversions, annotations, deleting/merging/etc, content editing, etc.? Is there a difference between applications?
My instinct is to play it safe and use Adobe, figuring whatever they do is the de facto standard. But I strongly dislike the applications and all the privacy invasions they impose. (Yes, I'm aware of PDF/A; I'm talking about applications' outputs and not the standards.)
Thank you for responding and congratulations on the success of SumatraPDF, it seems well-deserved.
I will say that on older systems, Reader/Acrobat are not just slow at startup. I am writing this from a machine that has an i7-2600 and 16GB of DDR3 RAM. Reader is almost unusably slow. It's absurd.
Acrobat Pro is pretty incredible. One of my favourite features is the following: on a scanned PDF after performing OCR you can edit the text and it will match the font. As in, it will create a new font based on the characters it found in OCR.
I’m a high school math teacher and scan dozens of textbooks every year. Adjusting a few words before printing to match what we did in class is a huge time saver for me.
Somehow my school division was able to buy me a one time fee perpetual license. I’m very happy with it.
For me even Sumatra or Foxit have too many features. I only ever open PDFs to read and print, maybe zoom, but all those other buttons there only distract me - if there'd only be a way to hide them... But yeah first world problems. I'm happy they exist.
It looks like it's Linux only (I only have Linux so I hadn't checked before), but when I want to sit down and properly read something, the keyboard-centric UI and minimalism make it a really smooth and frictionless experience.
In fairness, I didn't write the PDF rendering. That is indeed quite a tall order.
I used to use poppler and switched to mupdf (was more active at the time, poppler seems to have picked up pace since).
The core PDF feature set isn't that bad to implement.
From what I've seen, the bad / complex parts are:
- stuff they added years later, like some XML stuff (of course you had to add XML in 2000!), JavaScript in forms
- some more complex vector graphics features like masking with vectors, support for bunch of color spaces, cmyk separation
- font handling, text rendering is surprisingly complex
- rendering fast even if PDF was badly created
- PDF is easy to screw up when you create it and boy, do people screw up in every imaginable way. You can't just say "it's bad PDF" when Adobe or Chrome opens it so a lot of effort by mupdf devs is adding heuristics to show even broken PDF docs
When I bought my first computer in 2005, I discovered SumatraPDF and good lord it was miles better than the bloated alternatives. In particular, it was lighter and faster than everything else, which for someone like me who had to buy used hardware, was a godsend. So thanks for that!
Even once you have a parser itself, actually figuring out what to display and where is... interesting. Especially in generated rather than hand-created documents. What's the element's position? Grab your math library, we're multiplying matrices! What does this text say? Let's write another parser for the table of very custom codepoints!
If you change/transform then on the fly - sure. If they're on a final, not-designed-as-editable format... Not that common. I don't really see any reason (beyond PS origins and its historical usage) for PDFs to not flatten the final positions/sizes.
Please please don't mention 3d pdfs. Please. I had to implement this. 3d manipulation in a block inside of a print format that might make deliverables in the hundreds of gigs. It's . . it's one of the dumbest functional requirements I've ever seen, and the fact it exists. . I'm sorry, I have to go be by myself for a while.
The stupidest part of the whole thing is that pdf is basically a neutered postscript. The problem with postscript as a document format, is that there is no good way to do metadata, jump to a specific page, count pages, etc. So pdf uses the rendering engine of postscript with all that annoying turing complete behavior torn out. Then at some point they wanted some computational capability in the document[1], but instead of reintroducing postscript into the mix they went with a third language, a wierd poorly designed one invent for browser scripting.
1. Yes we all know how stupid this was. but they wanted fillable forms and validating those forms made sense at the time. Really it was because they were trying to compete with the web.
Having done that, PDF spec is in many ways much saner and better designed than plenty of "APIs" modern JS jockeys create.
The original spec is a bit ugly because they were saving bytes in the format (using things like single letters for dictionary keys), but some things are actually quite well thought out (Appearance Streams are great for forward and backward compatibility and are probably no. 1 reason why nothing managed to replace PDF.)
I think writing a parser for in-spec PDF files probably isn't too hard (though writing a complete renderer and interface certainly is), but many PDF files don't match the spec, so your parser has to be tolerant of invalid PDF files, because Adobe's is.
what I have been doing so far is switch between other modes with autohotkey by overwriting `SumatraPDF-settings.txt`. I'd share the little script but it suddenly broke a while back
Like others have mentioned, Sumatra is one of a few Windows-only utilities that I routinely miss when on Mac or Linux, primarily due to two simple interactions which I miss every day viewing schematics, mechanical/technical drawings or datasheets -- Alt + Scroll == Zoom and Right Click + Drag == Pan.
Does anyone know of any viewers on Mac or Linux that provide these two features? Skim on Mac implements Option + Scroll and Left Click + Drag Pan, but it's not reconfigurable to any other keys or mouse buttons.
Zathura does that under Linux, with the difference that zoom is achieved with Ctrl instead of Alt. Right-Click dragging = pan.
One feature I absolutely love is that Page Down goes to the top of the next page. It's very practical when you want to skim something quickly, with a zoom level that doesn't fit a page size perfectly.
I really like Okular (especially with the theme that allows me to read PDFs with dark red background and yellow text), but haven't been able to run it on my Mac Mini with Apple silicon. The brew formula appears to be broken for newer macs.
FoxIt does zoom on Ctrl+Scroll, and Pan on Left Click+Drag. Runs on Mac and I'd assume linux.
Close enough?
I assume if you REALLY want to go nuclear on it, there is some shareware app that will let you do per-app keyboard emulation and rebind inputs "in flight" or something.
evince (linux) does Zoom with Ctrl + Scroll, maybe yours does too? I don't think it has Pan, but I'm keyboard-heavy and use horizontal scroll with Shift + Scroll.
Middle button and drag moves the text wherever you drag it.
The evince feature I can't live without is the find, which shows a side panel with all matches in the document along with a bit of context. I wish all document find everywhere did this.
What's super handy about SumatraPDF is that it will auto reload normal image files if they're modified, so it's an easy way to get some sort of windowed graphics output by saving image files.
Not just images. Whole PDFs as well. I do some PDF generation for work, and running the update command and instantly seeing the changes when it’s done, is great.
I love SumatraPDF. I've used it for years and it is wonderful. I have been writing Latex in vim and I compile with the document open in sumatra side by side for instant updates. Very smooth workflow with the instant reload of the page.
Sumatra PDF was my go-to tool for viewing PDF changes in real time while writing manuscripts and thesis during PhD. Acrobat (paid) and foxit (free) have more features but locks the file undergoing changes.
Good example of how the implementation of unnecessary restrictions, without proper consideration of how such restrictions would impede users, can harm your product. I hope all software doing the same on android (safetynet, prevent screenshots, etc) follow Acrobat reader into irrelevance.
Sure, but for a viewer, deviating from that default makes a lot of sense.
I started using Sumatra years ago exclusively because of that feature. Exports/compiles failing, just because the PDF is still open somewhere is just unbelievably annoying.
Sumatra is great, though occasionally I wish it were possible to have something like Firefox's wrapped scrolling [1] where more than 2 pages can be shown side by side. On a reasonably large monitor, being able to quickly zoom out to see e.g. 30 pages (sometimes all the pages of a journal article) at the same time can be very useful. You can be on p. 20, then go and quickly look up a definition on p.2, then frictionlessly switch back to p. 20. Having to remember a page number to go back to, or a key word to search for, or to worry about where the "back" button might take you (as with most PDF readers) is just too much friction.
Love this view. I can't get pdf display on FF to invert colors. Is there a way? Then it would replace okular for me (which also does this overview mode)
Is there any open source seamless PDF editor available given how pervasive is the PDF document nowadays? I really think that we need one and it has been long overdue.
What I meant by seamless is that all of the open source software that currently able to edit PDF document is dong it in a clunky way at best for example Krita and LibreOffice Draw. The resulting edited output document also is also looks distinct, in a bad way, from the original document unlike the output from Adobe PDF editor.
Thanks for the link will try it out, apparently this app was initially made by ChatGPT, whatever that means
>This locally hosted web application started as a 100% ChatGPT-made application and has evolved to include a wide range of features to handle all your PDF needs
I have done extensive research in past when i was considering switching from mac to linux. Came to the conclusion that there is no viable open source alternative for the mac preview app unfortunately. My requirements where:
- Fill forms.
- Add text and markup.
- Reorganize/add/remove pages.
- Redact parts of the document. (should also safely delete underlying text data, without rasterization of the whole document)
- Add image of signature without rasterization of the whole document.
This [1] is a long discussion i found about the topic.
I really love SumatraPDF but I wish it'd fare better on the search story: there's no widget to show all search matches, afaik, and searching can be slow on really big files with thousands of pages.
To be fair, most PDF readers struggle with this, and I suspect only Acrobat attempts to cache or index files (as a Pro feature).
I'm really glad that they don't. I'd much rather have a safer PDF viewer that only supports a limited subset of what adobe's shitware does to handle 99% of my PDF file needs so that I only need to risk opening Adobe software 1% of the time. That's so much better than turning Sumatra into the same bloated mess of risky features that is Adobe Acrobat.
If you are on linux and miss the snappiness of sumatra, try llpp. They use the same renderer. In fact, llpp has more features, like a better overview mode where you can get 3 pages on screen. Search does suck. llpp is written in Ocaml and a fantastic piece of software.
I have the bad habit of keeping many PDF files in the reader open (yeah, I keep reading long books). The thing is when I open Sumatra for a new file (maybe only for a quick glance) Sumatra will reload all my files and slowed the startup significantly. I wish I can set the option which will load only if I’ve actually switched to the tab, just like Firefox.
Thank to your suggestion, I figured out a workaround:
- RememberOpenedFiles = true
- RememberSettingForEachFile = true
- RestoreSession = false
So Sumatra will open the new file without the ballast of the past. But if you click on an old file, it will open and go to the last position for you to continue. Right now one can not change the number of recent files list, nor can one replace the frequent access list with recent list, but I can live with that. Hopefully somebody could make these options.
It seems to have a bug where if you load a file from the app using the quick-load 1,2,...,10 keys in the File menu, then the next time you open another file in SumatraPDF from the explorer, it immediately opens several other files. This may be related.
The same frustration due to the same bad habit led me to look into implementing lazy loading in SumatraPDF, but unfortunately the code is structured in such a way as to make it a very non-trivial change.
It's kinda frustrating how by default, most major OS setups now are "open PDFs inside the browser". It's kinda nice that browsers can handle PDFs smooth-ish now, but Preview on Mac is nice, and SumatraPDF is as well.
It used to be Repligo, but it got removed from the Play store ages ago. I still had access to it, but since it wasn't being maintained, it became harder to use with each android os update.
I've been using Sumatra for what feels like a decade, and it's definitely the best PDF reader out there.
I mostly started using it for the auto-refresh when I'm working on a LaTeX document.
I haven't really felt the need for a dedicated PDF reader ever since Firefox upped their PDF support. It works pretty well and recently added support for form filling, text box and drawing [1].
SumatraPDF does support other file formats, which is nice.
Sumatra is one of the (few) win apps I miss since recently converting to linux. Running it under wine seems like overkill, but I wish for a debian port...
Sumatra makes heavy use of the win32 API so a port is not possible. This design is why it's so good (light, fast, well integrated) and the author refused to lessen his software by using a cross platform framework.
This is an important point - single platform apps for Windows and macOS or iOS or Android behave and look much better than cross platform apps let alone browser based apps.
I will put up with less functions for the better feel.
However many people want to appeal to more users or program in Linux or web and so have a default cross platform GUI anyway (or make it cross platform easily)
I thought I would too. But Zathura had been adequate over the years (similarly mupdf based). And I have been using sioyek[1] for few months and I probably like it the best.
Qpdfview is my daily driver for reading documents on Linux. Supports tabs, search, highlighting.
If you want something still more lightweight, Zathura would be the way to go. It can be a tad too minimalistic, but great for LaTeX with vimtex, and for an occasional quick document, the startup times are phenomenal.
I love Zathura under Linux. Bonus points for not attempting to do its own window management (tabs and whatnot) and leaving that to the window manager.
But one thing I really hate with it is that if you rename a file while it's open, it'll stop displaying it. Not sure if this is related to zathura itself or to the backend I'm using (mupdf).
SumatraPDF does not acquire a file lock on the pdf. This is really useful if you're debugging a process that outputs a pdf and you want to see how the pdf refreshes. With other readers the tool that tries to replace the pdf will fail as the pdf viewer has a lock on the file.
I got a love/hate relationship with PDF readers, and I find myself constantly switching from one to the other in hope of a better experience. All I want is to set my own exact colors and to use a hand-tool if I so wish. You wouldn't think that such simple wants should be an issue or, if what you did was making PDF-readers, that it may cross your mind to implement one or two of those.
On the other side of the spectrum you have Calibre, a program that uses a multiplatform abstraction, with a myriad of options, a myriad of icons, plenty of features...
In my opinion, I prefer the Sumatra way of doing things. But if you need to transform data... there is no other option that fighting against the multiple features of Calibre.
> This comes back to Jeff Bezos’ wisdom: there will never be a time when users want bloated and slow apps so being small and fast is a permanent advantage.
I have been using Sumatra for years and my only issue is that it sometimes takes a _very_ long time to get it to start printing a complex document (at least on Windows). I still keep Adobe Reader around just for printing.
When I'd used Windows Sumatra was the best; on Ubuntu, I use Zathura which is similar, fast and minimal. But I think most PDF viewers are more or less the same as they either use mupdf or poppler
Sioyek beats SumatraPDF for academic text work. Sioyek has Overview[0], Smart Jump and more features that helps academic text studies. Digital versions of page earmarks, pen highlighting and margin notes that are common in academic text usage. It feels like the main developer and contributors have personal experience of that kind of use and gear the application for it.
In contrast the SumatraPDF dev seems focused mostly on light, casual PDF viewing. Read short pdf files from start to end, add a few highlights, occasionally search.
One good feature SumatraPDF used to have, but removed, was an option to store annotations (such as colored text highlighting) in external .smx sidecar files. Similar to how VLC and other video players support sidecar .srt subtitle files.
Since a few years SumatraPDF now only writes annotations into the PDF file. That has some advantages (greater cross reader annotation compatibility, all in one file) but also disadvantages:
- Third party tools can't search or operate on the plaintext annotations. With the sidecar approach if highlighted text were to be stored as plaintext with location data in the sidecar file third party tools could use ripgrep or similar to do fast, powerful searching and filtering on highlights across a whole pdf collection.
- Annotation versioning.
- No convenient way to load different sets of annotations for a single file. Useful for academic text work where one source document may be highlighted differently for different research topics. With an API and support for third party tools toggling such sets could be instant and very user friendly. Without sidecar files the user has to keep separate copies of the pdf file and write different annotations to each.
- Modifying the source pdf can be an issue where text integrity is crucial. Many pdf documents are used as a shared source of truth and simple hashing can verify that all parties use the same unmodified document. That gets more complicated when annotations are written into the file, since different pdf applications do such writing differently.
Even though Sioyek is better for academic work I think there is a lot more to do. In some ways academic text work on a physical book still has a better UX. For example a glance at the edge of a physical book gives an overview of the earmark locations. A digital version of that would be a code editor minimap style sidebar that overview highlight and bookmark locations in the whole pdf document. The minimap could have a heatmap feature that colors (and gradually fades) locations the user recently has viewed in the pdf. As a way to mitigate getting lost when jumping between locations in a digital document.
Agreed. SumatraPDF is still one of my favourite programs, and I wish there was a Linux PDF reader which approached it. (Okular is probably the best, but it can’t remember opened tabs.)
This is amazing piece of software. You click the icon and it starts. Immediately. It does what you expect it to do, it just displays PDF file on the screen.
Is there any way to click on an image to magnify? in many books figures are too small. Ctrl + scroll does magnify the entire doc, but the img is pixelated.
I use preview all day, every day, often with dozens of files open, including full scans of the full OED (each pdf 100s of MB). It occasionally will hang when I "print to PDF" with a large document, but other than that no issues to report for a couple years now on M1 and M2.
Maybe it's just me, but they all happen to have issues when printing. No idea why or if it has been fixed recently, but I never had this kind of issue with Sumatra or Acrobat obviously.
Stopped using cause the author can't comprehend that scrolling / scrollbars could apply to document as a whole (like every other editor/viewer ever allows).
Hmm? I don't think "every other editor/viewer ever" does this. Okular doesn't do this for example, I just checked: If I use "Fit Page" and uncheck "Continous", the vertical scrollbar disappears.
I'd also find it confusing, because it seems like that means if you zoom in, the scrollbar would be for the current page, but then if you zoom out, it would be for the entire document. Is that how other viewers actually work, or is it more elaborate than that?
Obviously this isn't a model interaction with an open source project either way. Although I don't think how they responded was ideal, I don't think I would've enjoyed communicating with you on that thread if I were the maintainer, either. Nobody's perfect, but all in all, I'd hope you agree that this has thusfar not been very productive on either side.
He does, document level scrolling is the default behavior? Link looks like someone put it in a non-default view mode and doesn't like the specifics of how that mode works.
You can always submit a PR to implement the feature you want. Maybe showing the author what you want via PR is the best way to explain what you are asking for.
Since Adobe is pushing a more aggressive stance for monetization of Acrobat, I am trying to replace selected PDF workflows with OSS. Here are some of the tools I use.