[HN Gopher] Spotlight on pdfly, the Swiss Army knife for PDF files
___________________________________________________________________
Spotlight on pdfly, the Swiss Army knife for PDF files
Author : Lucas-C
Score : 297 points
Date : 2025-10-13 08:36 UTC (14 hours ago)
(HTM) web link (chezsoi.org)
(TXT) w3m dump (chezsoi.org)
| 5- wrote:
| curiously poppler doesn't mention that anywhere on their website,
| but the library comes with a similar suite of tools, typically
| available in linux distributions.
|
| i have found them very helpful.
|
| https://en.wikipedia.org/wiki/Poppler_(software)#poppler-uti...
| Hendrikto wrote:
| I use these all the time. They are great.
| Gormo wrote:
| Same, in conjunction with some of the format conversion tools
| that come with Ghostscript, and PDFgrep
| (https://pdfgrep.org/).
| zie wrote:
| I just used these tools to parse a few hundred thousand PDF
| paystubs to get data into our new financial system. 10/10 would
| use again.
| jopsen wrote:
| There is also: https://pdfcpu.io/
|
| That said, if you're looking for a GUI app to do simple PDF
| mutations it's often hard to fine a simple solid open source
| cross platform app.
|
| At least I haven't found one :)
| mschild wrote:
| If self hosting is an option, I've found Signature PDF to be
| quite good.
|
| https://github.com/24eme/signaturepdf?tab=readme-ov-file#sig...
| phyalow wrote:
| I had to bash my head against the wall and submit myself to
| paying for a creative cloud license. At least acrobat just
| works. Although I wish there was a reasonable alternative.
| emeril wrote:
| pdf-xchange is worlds better for just about anything in my
| experience
|
| can't believe I waited so long to try it out
| echoangle wrote:
| How about this: https://tools.pdf24.org/en
|
| It allows installation for offline use too.
| vindarel wrote:
| I found PDF SAM basic ("split and merge") well done:
| https://pdfsam.org/en/pdfsam-basic/. That one is open-source
| and multi-platform, they have more features in a paying
| superset project.
| unixhero wrote:
| Pdfsam and pdfxchange are my gotos
| 5- wrote:
| i've tried 'pdfcpu images list' on a random pdf i've had lying
| around and the tool unexpectedly started downloading some font
| from unspecified internet location to my local disk.
|
| sorry, too spooky even for october. :-)
| roschdal wrote:
| https://github.com/LibrePDF/OpenPDF
| blknight wrote:
| I'm curious: what good would automating signing a PDF through a
| utility do?
|
| The whole purpose of a signature is that a person signed and
| agreed to something. That cannot be done automatically.
| withinboredom wrote:
| CEOs often need to sign changes to employment terms or
| options/vesting terms and have hundreds if not thousands of
| employees. They don't have the time to go through and sign all
| of those contracts.
|
| Its no different than the analog ages where a secretary would
| go through and stamp all the contracts with the CEOs signature.
| nashashmi wrote:
| Those don't need certified signatures. They just need pdf
| stamps.
| withinboredom wrote:
| It depends on jurisdiction
| cyanydeez wrote:
| Pdf stamps have zero security.
|
| Signing can be cryptographic.
| lxgr wrote:
| Just because that's what many people still do doesn't make
| it sane.
| echoangle wrote:
| Why wouldn't a company sign documents they create
| automatically? This is about a cryptographic signature that
| lets the user verify authorship, not a visual signature in the
| PDF, right? So it would still be useful to be able to verify
| that a bank statement is really from my bank, even if it was
| generated without human interaction.
| arethuza wrote:
| Also allowing you to detect whether any changes have been
| made since the signature was applied.
| j1elo wrote:
| My bank can issue a signed certificate for any of you account
| movements if you need to provide proof of them. They come
| signed both digitally and handwritten by the branch's director.
| But you wouldn't expect the director to be there sitting and
| signing all certificate requests that arrive, right?
| pfortuny wrote:
| Imagine you need to sign 25 pdf documents. You read them on the
| screen and then batch-sign them (instead of signing them with
| the vewing software). This is just an example.
| reconnecting wrote:
| I though Swiss Army knife for PDF are Didier Stevens PDF tools:
|
| https://blog.didierstevens.com/programs/pdf-tools/
| SpacemannSpiff wrote:
| Pdftk has been been around for many years, and does exactly the
| same things. Why reinvent the wheel?
|
| https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
| QuantumNomad_ wrote:
| It makes sense to me. They made a PDF library for Python first.
| Having a PDF library for your preferred language is a good
| thing.
|
| And it's natural to then build a cli tool on top of the library
| they already made.
| alanbernstein wrote:
| This was my first thought, but after reading the comments here,
| I see I had no idea how many other alternatives already
| existed, so why not add another one.
| moopie wrote:
| It's not open-source, so practically the question is equivalent
| to "why reinvent the wheel by creating libreoffice when there's
| a perfectly good Microsoft office suite out there"
| mkesper wrote:
| The server component is under GNU GPL:
| https://www.pdflabs.com/docs/pdftk-license/
| forgotpwd16 wrote:
| In case anyone gets confused, _PDFTk Server_ is just the
| name for the CLI tool, which hasn 't been updated in 10y+
| (and annoying to compile due to newer GCC versions removing
| GCJ). The _pdftk_ provided in various distros (incl.
| Debian, Fedora, Arch, NixOS) is _pdftk-java_ , a 3rd-party
| pure Java port of the original tool.
| suhlig wrote:
| > Every time someone reinvents the wheel, it becomes a little
| rounder.
|
| Not sure if this particular library is an improvement, but even
| if it serves nothing but the author's enjoyment, or education,
| it's a win.
| theothertimcook wrote:
| Not the same thing but just want to shoutout
| https://www.pdfgear.com/ as one of the only viable alternatives
| to adobe for intermediate level PDF tinkering. It's free and
| available for everything except Linux.
| Chris2048 wrote:
| I found it suspicious, they formerly sent stuff too their cloud
| without it being obvious, and the company seems to mod their
| own subreddit.
| eyegor wrote:
| As nice as it looks, I have a lot of trouble believing the "we
| have magic money, it's free because that's good for business"
| logic. PDFgear is free of charge, and we
| don't generate income through any hidden means. We Do NOT
| misuse or sell user data and we Do Not display ads. Here's how
| we keep operations running: We've secured investment
| to cover operational costs, including team expenses and
| technology like the ChatGPT API. We're also experienced in
| optimizing technology usage to manage costs more effectively.
| darkwater wrote:
| They also say In the future, most features
| will remain free, but there will be a fee for some advanced
| options. Paid options may include AI-driven tools requiring
| cloud computing and special PDF conversion features. This
| balanced approach will allow PDFgear to remain widely
| accessible while meeting users' evolving needs with advanced
| solutions.
| hackyhacky wrote:
| > It's free and available for everything except Linux.
|
| I was unable to find the link for OpenVMS, Apple II, and DEC
| Alpha binaries, could you show me where to find it?
| lenerdenator wrote:
| In 1994.
| kmoser wrote:
| Easy, just run your favorite Windows or Mac VM on any of that
| hardware and the corresponding PDFgear binary will work out
| of the box.
| d3Xt3r wrote:
| There's also Master PDF, and it's also available for Linux:
| https://code-industry.net/masterpdfeditor/
| smartmic wrote:
| In addition to the already mentioned, there is also pdfcpu[0], "a
| Go PDF processor and CLI"
|
| [0]: https://github.com/pdfcpu/pdfcpu
| HelloUsername wrote:
| What about https://www.ghostscript.com ?
| layer8 wrote:
| For low-level work, _qpdf_ can be quite useful:
| https://github.com/qpdf/qpdf
| ripe wrote:
| Came here to say this. Qpdf is my go-to for manipulating pdf
| files on the command line. Encrypting, decrypting, extracting
| and merging pages.
|
| It's Apache-licensed and written in C++.
| voidmain0001 wrote:
| How do you use qpdf for extraction when its README states
| "qpdf does not render PDFs or perform text extraction, and it
| does not contain higher-level interfaces for working with
| page contents."
| ratrocket wrote:
| Not the person you're replying to, but when they said
| "extraction" I believe they're talking about extracting
| _pages_ from a PDF (like "splitting" the PDF apart, page-
| wise), not text. At least that's a thing I've used qpdf for
| in the past.
| BobaFloutist wrote:
| Which is also what the "extract" button does in Adobe
| Acrobat Pro DC for Professional Enterprise Customers or
| whatever they're calling it now, so it's arguably a term
| of art for PDFs.
| llm_nerd wrote:
| This is totally an aside, but I wonder how long the "Swiss army
| knife" metaphor will hang on in popular culture. People generally
| use it to indicate that something does a variety of things, but
| I'd say many of younger generation have never touched if even
| seen such a knife in their life, and even among older generations
| it doesn't have a positive connotation.
|
| Like when I hear something is the Swiss army knife of something,
| my take is that it does a lot of things poorly and there are
| better specific tools for every need. Like if you need a really
| terrible knife or bottle opener or screwdriver or saw, a Swiss
| Army knife has you covered. But it should be a tool of last
| resort when you have no other options.
| crazygringo wrote:
| Swiss Army knives seem to be as popular as ever. What do you
| mean, doesn't have a positive connotation?
|
| They're great hiking, camping, traveling, in backpacks and
| bags.
|
| What's wrong with it as a knife? It's perfectly sharp.
| Obviously it's not a full-sized _chef 's knife_, but it will
| cut your apple or twine or packing tape. It's a multitool. It
| does lots of things. A tool of "last resort" seems to miss the
| point -- it's not meant to use at home, when you have a full-
| size screwdriver and bottle opener and corkscrew. It's for
| traveling with you. And it's great at that.
|
| SAK's are iconic. I don't think your take is a common one.
| IAmBroom wrote:
| Be serious. If someone in 2025 has a pocket multitool,
| there's about a 1% chance it is red with a white cross on it.
| crazygringo wrote:
| ??
|
| Obviously it's not the _only_ game in town ever since
| Leatherman made the pliers-style tool popular as well.
|
| But you can just look up the various brands on Amazon to
| see that SAK's continue to sell very well, by "x bought in
| the last month."
|
| It's nowhere near 1%, I don't know where you're getting
| that.
|
| Edit: according to [1] Victorinox has the _#1 spot_ in
| market share in multitools. The share is a bit higher than
| it is for SOG and Leatherman, though they 're both close.
|
| [1] https://www.marketreportanalytics.com/reports/swiss-
| army-kni...
| IAmBroom wrote:
| I stand corrected.
|
| Amazed, but corrected.
| jacekm wrote:
| Lots of cheap (and good) Chinese alternatives entered the
| market recently but I'd say Victorinox is still going
| strong. In Poland it's sold everywhere and the brand is
| very recognizable.
| mebizzle wrote:
| Victorinox makes one of the better ones though theyre just
| pricey. I like my MXBS.
| llm_nerd wrote:
| >Swiss Army knives seem to be as popular as ever.
|
| It isn't as popular as ever, at least not in the Western
| world. I don't know what your frame of reference is, but it
| is positively non-existent compared to a couple of decades
| ago. Approximately zero kids, give or take a few, put one on
| their Christmas list, where when I was a kid it was many
| kid's dream item. I would say the most common buyer today are
| middle-aged men who buy it just as a thing to own because
| they remember how desirable they were when they were in
| Scouts in their teens.
|
| >A tool of "last resort" seems to miss the point
|
| It is quite literally a tool of last resort, and in practice
| people who actually own one (such as myself) have often
| never, ever actually used any of the options available on it
| because they're terrible options and we always have something
| better available.
|
| Like a legitimate folding camping knife, which we all have in
| our camping supplies. An infinitely better knife. A tiny
| multi-screwdriver kit. The Leatherman brand went big by
| making a legitimately good, well constructed pair of pliers
| that they add some "in a pinch" options.
|
| Serious campers who portage and go deep country have a proper
| assortment of gear and never lean on their SAK. The rest of
| us usually get there in a car and have a...proper assortment
| of gear.
|
| But again, if you're in a situation where you have to use one
| of the tools on a SAK, you probably screwed up and it's a
| serious compromise. It just isn't a compelling metaphor for
| software tooling.
| crazygringo wrote:
| See my other comment for its popularity statistics.
| Victorinox is literally the #1 multitool brand by market
| share. These are facts.
|
| Your take is idiosyncratic. Using a SAK doesn't mean "you
| probably screwed up". That's truly a bizarre thing to say.
|
| A SAK is a perfectly fine metaphor. That's why it's a
| popular one. It's a small tool that does lots of things. I
| think you're overthinking this.
| llm_nerd wrote:
| >Victorinox is literally the #1 multitool brand by market
| share
|
| This doesn't repudiate anything I said, and it's a
| particularly weird canard.
|
| >That's why it's a popular one
|
| Increasingly the only ones I see leveraging the metaphor
| are English as a second language writers (note that the
| idiom originates in English and is a calque in other
| languages) who perhaps came across it somewhere. I would
| hardly call it "popular", and I pointed out the reality
| that many readers, such as myself, find it a _negative_
| description, similar to someone calling themselves a
| "jack of all trades". Your defensiveness of SAK does not
| change this, and your attempts at invalidating my
| statement borders on bizarre.
|
| Feel free to continue. I'm done here.
| crazygringo wrote:
| > _are English as a second language writers who perhaps
| came across it somewhere_
|
| Your prejudice is showing. Where would you even get an
| idea like that?
|
| I hope you understand that people whose first language
| isn't English also use SAKs. It's not just an English
| thing. They're not trying to repeat some unknown object
| they've only encountered in metaphor. The tools are
| literally _Swiss._ And popular around the entire world.
| hbarka wrote:
| You're absolutely right. I was just in Switzerland and
| I'll tell you the Victorinox shops have endless visitors
| from all kinds of tourists. Swiss Army knife metaphor is
| timeless, at least for those who go out. Maybe there's a
| generation where outdoor activities is an unknown because
| computers. At this point the other person is just being
| argumentative.
| llm_nerd wrote:
| _I 'm_ being argumentative? Uproarious.
|
| Arguing that my observations are invalid because you were
| in a Victorinox shop in Switzerland is the chef's kiss on
| this ridiculous discussion.
|
| In the future, just move along. The other argumentative
| guy had no reason to get defensive about SAK, and this
| whole worthless discussion, from a basic observation
| about idioms and ill-suited tools, is a waste of bits.
| gpvos wrote:
| _> This doesn 't repudiate anything I said, and it's a
| particularly weird canard._
|
| It does repudiate it, directly. What are you on about?
| llm_nerd wrote:
| It doesn't remotely repudiate anything I said, more than
| saying that Gpvos is the #1 seller of buggy whips ergo
| ipso facto buggy whips are super popular. This is not a
| hard logical chain to follow, so good god.
|
| But secondly, even that site claimed they have what, a
| 20% marketshare of multitools from once owning the market
| entirely to themselves? Even if we were so profoundly
| simple that we believed that being the biggest vendor in
| a market validates the market, this particular example is
| hilarious.
| crazygringo wrote:
| If you opened the link, literally the first line says:
|
| > _The Swiss Army Knife (multi-tool) market, currently
| valued at $402 million in 2025_
|
| Nearing half a billion dollars doesn't sound like buggy
| whips to me.
|
| And the bar chart clearly extrapolates the market
| continuing to _grow_. Not shrink.
|
| But you still think the #1 brand in a large and growing
| market is "positively non-existent"...?
|
| Again, for convenience:
|
| https://www.marketreportanalytics.com/reports/swiss-army-
| kni...
| nic547 wrote:
| For me it's a bottle opener, a corkscrew and a knife that's
| good enough.
|
| More picnic less camping in the wild.
| pseingatl wrote:
| 9/11 killed them. They used to be sold in airports.
| IAmBroom wrote:
| I'm not clear why you think the majority of sales were in
| airport shops.
|
| Ring neck pillows, maybe.
| IAmBroom wrote:
| And thus the Leatherman(tm) was born from its ashes.
|
| And too quickly smothered in copycats for its name to become
| the new metaphor.
| aswegs8 wrote:
| TIL: there are numerous swiss army knifes for pdf files available
| already
| VeejayRampay wrote:
| due to the nature of PDF, none of the tools mentioned here can do
| things as simple as detecting tables on pages with high accuracy
|
| PDF is absolutely mint for display but it really suffers when
| parsing is involved
| WillAdams wrote:
| Yeah, I've been expecting someone to work up a system where:
|
| - source file is .md
|
| - file is compiled to .pdf _and_ the .md source file is
| included as an attachment
|
| - when working with the file beyond viewing as a .pdf the .md
| is extracted and used instead of the .pdf
|
| The LaTeX folks have a similar system ages ago where the .tex
| source would be included in a .pdf made from a .tex file for
| embedding in documents so that it could be sent in say an
| e-mail and then edited by the recipient --- absolutely awesome
| for discussing math via e-mail.
| apf6 wrote:
| That's a good concept but I don't think Markdown is
| expressive enough for all the layouts & formatting that
| people typically want in PDFs. More likely that the source
| format would be something like HTML or SVG or .docx.
| kevin_thibedeau wrote:
| Restructured text has mostly 1:1 correspondence with
| Docbook. I use an XSLT transform to convert its XML schema
| into Docbook and PDF from there via XSL-FO.
| bix6 wrote:
| Is this an alternative to acrobat?
| JackC wrote:
| Opinion from 10 years ago, I suspect still valid:
|
| There are a million python libraries and tools to do some
| overlapping subset of the things you'd want to do with a pdf.
|
| There are no doubt another million in other languages.
|
| These are each basically bundles of some of the transformations
| you'd want to make to the same underlying data structure.
|
| So, complex pdf scripts often need two or three different
| libraries to get their thing done, which is wasteful at borh a
| dev effort and computational level.
|
| The ecosystem would be greatly improved if someone made a great
| (probably rust based) in-memory low level pdf reading and writing
| data structure.
|
| PDF libraries in any language could switch to using that
| structure and library internally, with the carrot that the switch
| would result in needing less code, and likely being some
| combination of faster and safer.
|
| And then if they just exposed get_structure_pointer() and
| set_structure_pointer(), they could all interoperate for free.
| (Another carrot for joining -- small libraries could usefully add
| features and be adopted without needing to pick an existing
| popular library to glom onto.)
|
| Not sure what would economically cause this to happen, but it
| would be great.
| layer8 wrote:
| When you write a PDF library, there are design trade-offs all
| the way down, depending on use cases. (Just "in-memory" is
| already an important design trade-off, because the PDF format
| is intentionally designed to not require the whole PDF to be
| loaded into memory at once.) It would also be antithetical to
| preferring deep modules with minimal interfaces over shallow
| modules with broad interfaces [0]. Lastly, in managed
| environments like the JVM, a C-interface library would come
| with additional complications and overheads.
|
| [0] https://dev.to/gosukiwi/software-design-deep-modules-2on9
| whizzter wrote:
| Actually debugging a PDF parsing issue as we speak and actually
| started writing a parser (partially to understand the issue,
| partially as a last resort as the code in the parser I was
| debugging felt a bit shoddy).
|
| The PDF format is frankly quite horrible, extended over the
| years by kludges that feels more or less like premature
| optimizations in some cases and bloated overkill in others.
|
| While theoretically a nice idea, the issue is that there is
| just so many damn object types with specialized properties
| inside a PDF that you'd basically end up with all complications
| of a FFI for each binding you'd do to expose a sane subset.
|
| Theoretically one could perhaps make a canonical PDF<->JSON or
| similar mapping from an established library that most PDF data
| consumers/generators could use if memory usage isn't too
| constrained (because the underlying object model isn't entirely
| dissimilar).
| whenc wrote:
| You can do: cpdf -output-json in.pdf -o
| out.json
|
| (Modify out.json as liked) cpdf -j out.json
| -o out.pdf
|
| (Disclaimer, I wrote it.)
| conradev wrote:
| The ecosystem would be greatly improved if someone made a great
| (probably rust based) in-memory low level pdf reading and
| writing data structure.
|
| https://github.com/J-F-Liu/lopdf
| zehaeva wrote:
| I don't think this _really_ contributes to the conversation,
| but I think we can sum this entire post up with just one XKCD
| comic.
|
| https://xkcd.com/927/
| specialist wrote:
| > _someone made a great ... in-memory low level pdf reading and
| writing data structure_
|
| Are you suggesting Adobe's Core Object Application Programming
| Interface (COAPI) for PDF isn't sufficient?
|
| Kidding!
|
| I worked on print production software in the '90s. Stuff like
| image positioning (eg bookwork), trapping, color separations,
| etc. Adobe's SDKs, for both PostScript and PDF, were most
| turrible. For our greenfield product for packaging (printing
| boxes), I wrote a minimalist PDF library, supporting just the
| feature set we needed. So simple.
|
| Of course, PDF is now an ever growing katamari style All The
| Things amalgamation of, oops, sorry I ran out of adjectives.
|
| Back to your point: after URLs and HTTP, the DOM is the 3rd
| best thing spawned by "the web".
|
| The DOM concept itself. Isomorphism between in-memory and
| serialized. That its all just an object graph. Composition over
| inheritance.
|
| Not the actual DOM API; gods no.
|
| I understand that API design is wicked hard. But how is it that
| of the Java tools, only JDOM2 (the sequel) managed to get the
| class hierarchy correct? So that incorrect usage is not
| permitted?
|
| (I haven't looked at popular libraries for other languages. I
| assume they all also fell into the trap of transliterating
| JavaScript's DOM's API. Like dom4j and successors did.)
|
| I'm just repeating your point (I think) that Adobe should have
| staked a strong starting conceptual position on PDF internals,
| what a PDF is. Something more WinForms and less Win32.
|
| 30+ (?!) years later, I'm still flubbergasted by PDF's success,
| despite Adobe's stewardship.
|
| PS- And another thing...
|
| For a print description language, I greatly preferred HP's
| PCL-5. Emotionally, it just feels more honest somehow.
| Initially, Adobe couldn't decide if PDF was for print control
| or documents. Customers wanted documents, so Adobe grudgingly
| complied, haphazardly.
|
| At least "the web" had/has committees.
| mannyv wrote:
| "Adobe couldn't decide if PDF was for print control or
| documents"
|
| Apparently people don't understand the history of PDF. PDF
| was originally a way to encapsulate PostScript so you could
| display it on a screen. Unlike PCL, Postscript (and PDF) were
| device-independent, with a WYSIWYG guarantee. Postscript and
| PDF are literally the history of WYSIWYG on personal
| computers and computer-based printing/typesetting.
|
| PDF is not "print control" in the sense of a job control
| language. PDF has always been about documents, and the
| features of PDF files can be seen as an attempt by Adobe to
| both drive and follow the market's evolution of document
| handling.
|
| PDF is complicated because it's used widely for lots of
| different things, including printing. And if you've never
| worked in the printing industry you have no idea how much of
| a PITA it is.
|
| PDF succeeded for a lot of reasons, but probably the easiest
| explanation is that they were easier to create - you just
| printed it and the PDF printer driver spat out a PDF file
| that you could share everywhere.
| sleepybrett wrote:
| One of my first jobs was at an isp/web/cohost company. We
| had a big bank of modems for dialup customers, had some
| customers who terminated isdn with us, a rack of colocation
| and built websites as well.
|
| The company was partially owned and housed primarily in a
| print shop, we worked above the press floor and I was
| sometimes pressed into service helping when we were slow (I
| had some experience working in a print shop in highschool
| (helping with pagemaker and helping to run the big
| hidleberg), similarly in college.
|
| Nothing like ending your day writing perl cgi scripts and
| troubleshooting customers damn winsock configurations and
| then going home and coughing up whatever color was running
| on the presses that day.
| kmoser wrote:
| > The ecosystem would be greatly improved if someone made a
| great (probably rust based) in-memory low level pdf reading and
| writing data structure.
|
| > Not sure what would economically cause this to happen, but it
| would be great.
|
| Writing a library that is better than all the others is
| difficult to begin with. Continuing to upgrade and maintain it
| and fix bugs is even more difficult. Even with the right
| funding, you'd have to find someone who wants to keep at it
| year after year. When they inevitably lose interest, you'd have
| to find somebody else to take the reins--and weather the storm
| of complaints during the down time.
|
| In short, thank you for volunteering to write and maintain this
| library for the rest of your life! :)
| montefischer wrote:
| One feature I would love is the ability to automatically generate
| the table of contents / "outline" metadata for a pdf. I run
| across a lot of old book pdfs without that metadata, which makes
| navigation annoying. Kybook3 has a version of this that doesn't
| quite work. Maybe in the age of LLMs, this is now feasible.
| cratermoon wrote:
| I use https://github.com/Krasjet/pdf.tocgen.
|
| It's not quite fully automatic, but it certainly saves a lot of
| time over doing it completely by hand.
| montefischer wrote:
| Very nice! I'll check it out.
| laserbeam wrote:
| This, is gorgeous! I absolutely hate the PDF ecosystem, and how
| painful it is to get a reasonably simple tool to just do basic
| edits to files (adding/removing pages, combining multiple PDFs
| etc). I particularly hate how hard it is to find good swiss army
| knives for it, and how you always land on sketchy websites to do
| simple things to a file.
|
| This looks dead simple to use! LOVE IT.
|
| The one feature request I have is for adjusting margins
| (adding/removing fixed amount of space from every page,
| optionally adding/removing different amounts from odd numbered
| pages). Target audience: People who want to read PDFs on small
| ebook readers.
| Western0 wrote:
| I have similar tool its name TeX
| pgtan wrote:
| Actually pdftex or luatex, but you are completely right, it can
| load a pdf file and do a lot of things with it.
___________________________________________________________________
(page generated 2025-10-13 23:00 UTC)