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).
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.)
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!
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".
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.
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.
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.
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.
> 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.
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.
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. 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.)
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)
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).
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.
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.
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.
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.
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.
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.
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 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)
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.
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.
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.
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.
275 comments
[ 19.7 ms ] story [ 4785 ms ] threadhttps://forum.sumatrapdfreader.org/t/display-scrollbar-in-si...
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.
To be fair, most PDF readers struggle with this, and I suspect only Acrobat attempts to cache or index files (as a Pro feature).
Haven't personally compared the options but for me sumatra zathura and sioyek all feel fast enough to not notice any problems.
https://ahrm.github.io/jekyll/update/2022/09/11/pdf-viewer-t...
"Now I must admit, the reason sioyek is so fast is because it creates a search index when you open the document."
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.
RememberOpenedFiles = false
https://www.sumatrapdfreader.org/settings/settings3-4-6
- 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.
But I wish that I was able to ”drag and open in new window” tabs of different opened PDF files.
But I must say that skim for Mac is the best!
If so, you can do in latest update [1]
[1] https://github.com/sumatrapdfreader/sumatrapdf/releases/tag/...
Am I the only person who has Preview.app constantly hang and/or freeze my Mac, even on the smallest of PDFs (< 3 slides)
I’m on M1 with latest macOS.
open - edit - reload - edit - reload - edit - Preview crashes - reopen - edit - reloads - edit - Preview crashes etc.
*Which you are most likely using, since it integrates with Sumatra out of the box. And with MuPDF. And Skim, etc. It's cool like that.
I tried Sumatra a while ago, before switching over to Linux. It seemed pretty decent, nice and snappy.
[1] https://github.com/sumatrapdfreader/sumatrapdf/releases/tag/...
[2] https://github.com/sumatrapdfreader/sumatrapdf/issues/3672
Not yet but I'm thinking about how to improve it. Maybe next version.
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.
Don't use Android 6, unless completely offline, or on a local-only network.
https://tcpdf.org/examples/example_014/
How does this even work?
You can also do animated page transitions like PowerPoint, but I don't have the right link available...
To me this is the kind of scope creep that causes a "simple" PDF renderer department to end up with 50 devs working in it full-time.
I wonder... can a PDF have an iframe that opens itself? Causing an infinie loop of it loading itself?
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.
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've been wondering why they took that approach. Do you know their original reasoning? And how does it help compatibility?
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
Lessons learned from 15 years of SumatraPDF, an open source Windows app (2021) - https://news.ycombinator.com/item?id=35065785 - Mar 2023 (173 comments)
Seems like the author didn't look at cross-platform toolkits since 90s.
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.
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)…
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)
EDIT: Another commenter suggest only office as example. IIRC, they are building it using chromium as front-end and .NET as backend.
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.
That's fair in the sense that I did not look closely at latest Gtk or Qt or WxWidgets.
That being said they certainly did not get lighter.
Last I checked Qt was over 10 MB of libraries). Sumatra is 12 MB and I'm guessing over 8 MB is fonts needed to render PDF documents.
So just Gtk or Qt code would be more than the whole app.
Latest Gtk4 does seem to look nice so maybe calling it ugly was uncalled for.
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.
[1] https://helpx.adobe.com/reader/system-requirements.html
> 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.
Edited for formatting.
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.
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.
1. https://m.youtube.com/watch?v=EZ05e7EMOLM
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.
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.
Which of their products are you considering?
What Data Warehouse software do you write for RIS? Maybe I can use it :D
...and yeah Radiology communities are rare. I'm still looking for one...if I have time.
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.
...
> 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.
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.
That's the main value of automated tests.
seek forgiveness rather than permission - gets you launched - gets you better
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.
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)
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.
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).
[1] https://sioyek.info/
Disclosure: I’m the developer behind it
When we need to sign or view some complex documents then I'll use Acrobat.
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.
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.
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.
I believe https://www.keyboardmaestro.com/main/ is the standard solution.
It actually runs better under wine, with all sorts of errors that pop up because its updater Service can’t be found.
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.
You can use Karabiner Elements + BetterTouchTool to rebind that when Skim is in the foreground?
SumatraPDF does support other file formats, which is nice.
[1] https://www.mozilla.org/en-US/firefox/features/pdf-editor/
it is available in their Tools menu (the >> icon)
It has dual page view and the option for odd or even page split - addressing your first page left/right concerns.
The author was one of the most active members of the old Business Of Software forums, IIRC.
I always wondered how he could make money from a free PDF viewer.
[1] https://superuser.com/questions/1365482/how-to-view-a-pdf-wi...
Works very well under WINE on FreeBSD and does not have display issues with taskbars etc.
What the hell is Adobe doing, I wonder, that makes their software so unbearably slow and painful to use?
Maybe they're handling every posts feature wish list?
Like every comment so far here is Sumatra is nice but...< Some random feature > is missing
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’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.
There's a mupdf windows build. Perhaps that will do what you want.
(Mupdf is also a library so there are a lot of different programs with the name in it by various programmers.)
https://wiki.gnome.org/Apps/Evince
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.
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.
Sumatra includes a 3D renderer to display embedded CAD models? https://helpx.adobe.com/acrobat/using/displaying-3d-models-p...
As for startup speed, it's not really an issue as Adobe just lurks there all day in the taskbar for me at least ready to roll.
More / better annotation editing, signing, redaction is something I want to do.
OCR - I don't have a good handle on how important that is.
I would much rather throw this money your way, but I need those features
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.)
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.
Now where's that Mac port? /s
Yes, printing is not great. Actively considering making it better, maybe in next version.