gettalong

Why is it that everyone now duplicates/vibe-codes PDF tool websites? It seems that there is one new each week for about half a year now with none providing any outstanding features over the others.

If it can only be viewed with your web application, it won't be useful for the general public.

PDF already has the notion of portable collections (PDF 2.0 section 12.3.5). As far as I can determine this is very similar to what you do except that your pdfx format won't be supported by (major) PDF viewers/libraries.

I usually use pdfpc (https://pdfpc.github.io/) for this which works like a charm. No internet access needed, content stays on the computer.

Regarding "Important Notice on Third-Party Components": You are including AGPL components in your project which itself is AGPL.

Even if you distribute your part of the code under the commercial license, the components make - depending on how they are integrated into BentoPDF - the whole project AGPL again. So it might be possible that all your commercial customers are breaking the AGPL of the included components. For example, if your code directly calls code in the components, the integration is tight and AGPL would most certainly apply. If all you do is call the components as external binaries, then it is fine.

In case you don't know it: PyHanko provides a full and up-to-date implementation for digital signatures in PDF, including time stamping.

https://github.com/MatthiasValvekens/pyHanko

Yes, creating a binary and calling that would circumvent the AGPL. But then everything will be more complex and slower.

Also, doing this extra work and developing the binary is probably more expensive than just buying a commercial license.

I'm not a lawyer but I think you mistaken in this regard. One indication for this is that otherwise some major companies would have problems.

For example, the GPL FAQ has the following part in the FAQ item title "What is the difference between an 'aggregate' and other kinds of 'modified versions'?" (https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation):

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

A combined work needs to be distributed under the AGPL, an aggregated work does not. Since Ruby is interpreted the code of HexaPDF loaded from the application would run in the same address space and thus it would be a combined work.

The following two links are also relevant: https://opensource.stackexchange.com/questions/5003/agplv3-s... and https://opensource.stackexchange.com/questions/5010/can-i-us...

The library is dual-licensed as AGPL plus a commercial license. So everything is in the open and can be tested and tried out under the AGPL. Once the library is used in a commercial context, you nearly always need to buy the commercial licenses to stay compliant. This is how it generally works.

What the commercial license does is a different thing. You could charge once OR once and for every upgrade to an (arbitrarily defined) new major version OR each year via a subscription OR ... It is really up to you and how you want to handle this.

Thanks and corrected!

Thanks!

I agree that laying out PDFs could be made easier by using a declarative mechanism instead of coding. However, I'm still not sure what the best way would be to do that. Using HTML/CSS for this and doing it right would entail implementing something like PrinceXML...

With the current layout model you have the possibility to implement price layouts, like the one needed by Swiss QR bills (see https://x.com/_gettalong/status/1748823670368117154), or just define the general layout and let HexaPDF decide the final position (see https://hexapdf.gettalong.org/examples/pdfa.html).

If you have any ideas, how laying out PDFs could be made simpler, I'm all ears!

You can get a long way with only implementing the most basic things of the PDF specification, like section 7. And even there you don't need everything. For example, there is no need to implement the CCITTFaxDecode, JBIG2Decode, DCTDecode or JPXDecode filters if you don't want to get at the raw pixels of the images.

Once you have parsing and writing of a simple PDF file going (sections 7.2, 7.3, 7.4, 7.5, 7.7), add in support for encryption (section 7.6). Now you are able to handle to at least parse and write nearly all PDF files.

Then implement all the things you need gradually For example:

* Need support for parsing or creating the contents of a page? -> sections 7.8, 8, and 9. Mind you, start out with only supporting the built-in PDF fonts for creating text and later add support for TrueType (easier) and OpenType (harder if you need to implement the font parser yourself).

* Need support for annotations? -> section 12.5

And so on.

If you just need to store the metadata in the PDF, you only need support for parsing and writing a PDF because this usually also entails that you can modify the PDF object tree which is needed for storing the metadata. However, if you need to store that metadata in a way that is usable for other PDF processors, you would need to store it as an XMP file and creating that is yet another deep dive if you don't have an XMP library available. See section 14.3.2 in the PDF spec for this (btw. the latest PDF spec is available at no cost at https://pdfa.org/resource/iso-32000-2/).

Many PDF viewers and library do not fully follow the PDF standard or have subtle bugs. This leads to problems later on.

My guess is this all started many years ago when Adobe Reader was the standard PDF reader and it was (and still is) very lenient when it comes to PDFs that aren't exactly following the specification.

So what did everyone else? They followed Adobe's lead because "But, but, ... it works in Adobe Reader!"

Thanks - that helps!

Thanks for your answer! I imagined you would be using PrinceXML behind the scenes since that is probably the gold standard in HTML+CSS rendering.

The only open source alternative I know of is WeasyPrint at https://weasyprint.org/. I'm not sure how well it fares against PrinceXML, though.

And thanks for the pointer to Taffy - I didn't know it before!

What are you using to generate the PDFs? Are you doing something like PrinceXML (or weasyprint) which directly convert HTML+CSS to PDF? Or are you converting HTML+CSS to something else?

Are there any demo pages where it is possible to view the generated PDFs? I would imagine this would be easier to do since this is all based on Javascript.

It may be a valid HTML and JPEG (didn't check) but it is definitely not a valid PDF file. For example, it is missing the version identifiers in the PDF header, there is no cross-reference table and there is no PDF file trailer.

There is no reason to abandon PDF. As was already stated the main purpose of a PDF is viewing something as the author has intended, it should not be dynamic like a website. And editing is possible but not the intended use-case (and therefore harder to get right).

As for merging PDFs you first need to know what the user wants. Just merging the pages? Or should AcroForm forms be merged? Should the outline be merged, too? Depending on the answers you can then proceed with the merge. Simply page merging can be done with any tool, merging AcroForm forms or outlines may require more advanced tools.

PDF is actively worked on at multiple fronts, for example, support for HDR, newer image formats, maybe variable width font embedding, better re-flowing capabilities when this is needed (e.g. for small-screen devices)...

And with the ISO PDF 2.0 specification now freely available, anyone can join in :)

It seems that the news hasn't spread far yet but due to sponsorships by various big PDF related companies the ISO standard for PDF 2.0 is freely available, see https://www.pdfa-inc.org/product/iso-32000-2-pdf-2-0-bundle-...

While the PDF 1.7 spec from Adobe was always available, once it was turned into an ISO spec (ISO 32000-1:2008) it became paywalled. Due to an agreement with Adobe, the ISO version of the PDF 1.7 spec was made available free of charge. However, the further development of the PDF standard was done according to ISO rules and that meant paying for the standard... until the PDF association and a few companies stepped up and made the spec free again (also see https://www.pdfa.org/sponsored-standards/).

If you need a state of the art CLI tool for signing PDFs that supports the latest standards (think ones from 2023), I can recommend pyHanko (https://github.com/MatthiasValvekens/pyHanko/).

So I uploaded one of my standard test files for compression and it actually expanded the file size from 52K to 93K while making the images blurry.

Fair point :) And yes, some PDFs use weird ways to represent the spacing between words.

So, I don't think that the first two parts, converting the PDF page to an image to get the text, is necessary. One could just use the basic information in a PDF content stream to get the bounding box for each character. The resulting information can then still be analyzed using the layout analysis algorithm mentioned as step 3.

The information would also be more exact since extracting the character positions from an image depends on the rendering of the PDF to the image (i.e. if an A4 page is rendered at 300ppi or at 600ppi or higher).

The content of a PDF file is not like the content of, say, an HTML or ODT file. With the latter you use plain text with formatting instructions and the application needs to do all the layouting stuff, like glyph positioning (which is already a hard task), paragraph layout (Where to break the lines? How many lines for widows? ...) and so on.

A PDF file is essentially pre-rendered. So the application creating the PDF file needs to do all the stuff mentioned above and the PDF itself just contains the instructions at what exact position on the page which glyph should be rendered.

This makes displaying or printing a PDF much easier (but still a hard task). And that is also the reason why editing PDFs is hard because all the additional information like what is a paragraph, a heading ... is usually not available.

FYI: Tagged PDF has all that structural information and there are developments to allow e.g. reflowing of PDFs on smaller devices.

Yes, I know but thought it would be simpler to just say Shopify. Sorry for the inaccuracy.

Yes, it is slower but not that slow, e.g https://hexapdf.gettalong.org/documentation/benchmarks/optim...

Yes, there was a bit of a drop off in performance but only when YJIT is not used. With YJIT there are performance gain. Also note that YJIT in 3.1 was still experimental and more proof-of-concept. Only with the 3.2 release was it now deemed production ready.

And YJIT's creator, Shopify, is already using it in production with Ruby 3.2 for all their store fronts!

Yes, COW was implemented a few versions ago and the garbage collector also supports it to avoid unnecessary copying.

As others have already written, there are many slightly invalid PDF files out there in the wild that many readers can display mostly fine and which your library should also be able to handle.

If you can, grab yourself a copy of the most recent PDF 2.0 specification since it contains much more information and is much more correct in terms of how to implement things. Also have a look at the errata at https://pdf-issues.pdfa.org/32000-2-2020/index.html.

As I'm implementing a PDF library (in Ruby), I have started to collect some situations that arise in the wild but are not spec-compliant, see https://github.com/gettalong/annotated-pdf-spec. That might help you in parsing some invalid PDFs

I don't think LetsEncrypt provides such a service. Additionally, the certificate must/should come from a CA that is included in the AATL (https://helpx.adobe.com/acrobat/kb/approved-trust-list1.html), otherwise you won't get the nice visual check mark that the signature is okay on Adobe Reader (and, let's face it, this is what most people are probably gonna be using on Windows).

Agreed on cumbersome, I have a PNG file with transparency containing my signature and use Xournal++ (https://xournalpp.github.io/) for placing it on the PDFs. That works fine but still takes more time than I want to spend. But it's faster than typing it out every time.