We generate pdf files using weasyprint (convert html+css into cool pdf files), I think tools like this are very valuable and practical for building higher-level pdf-generators tools.
Yep, in-house PDF generators should be some sort of good middle ground, but I dunno if this 'weasyprint' is open source, is _lean_ open source? (no c++, java, etc).
When dealing with an ultra-complex file format which cannot be dodged, usually a good way to deal with it is to only use a very simple but coherent subset and enforce this usage with validation tools.
For instance, the web, noscript/basic (x)html (or you are jailed in the 2.5 web engines of the whatng cartel).
With PDF, I dunno much of the format (since I did not manage to download easily the specs), but when I have to print some text, I have a very small PDF generator for that (written ~25 years ago, so no utf-8 for me).
But what's important: such attempt must be sided with re-assessing the pertinence of the usage of the information systems, and yes, it will annoying and much less comfy and that MUST be acknowledged before even trying.
And big tech is not the only one trying hard to do vendor and developer lock-in.
> usually a good way to deal with it is to only use a very simple but coherent subset and enforce this usage with validation tools
You’re right, that’s exactly what we do. We support a growing subset of HTML and CSS that’s documented. We also use the W3C testing suite for HTML/CSS, and PDF validators, on top of custom unit tests.
> And big tech is not the only one trying hard to do vendor and developer lock-in.
We "only" follow open specifications and refuse vendor-specific features to avoid lock-ins (equivalent closed-source tools love that). And we even love the other open-source "concurrents": ♥ to Paged.js and Vivliostyle, try them, they’re great too!
You can learn more about weasyprint on their website (https://weasyprint.org/ ). It's an open source Python package that can be launched using cli or from Python code.
It uses pypdf, which is "pydyf is a low-level PDF generator written in Python and based on PDF specification 1.7" (from their README at https://github.com/CourtBouillon/pydyf ).
sylware|8 months ago
When dealing with an ultra-complex file format which cannot be dodged, usually a good way to deal with it is to only use a very simple but coherent subset and enforce this usage with validation tools.
For instance, the web, noscript/basic (x)html (or you are jailed in the 2.5 web engines of the whatng cartel).
With PDF, I dunno much of the format (since I did not manage to download easily the specs), but when I have to print some text, I have a very small PDF generator for that (written ~25 years ago, so no utf-8 for me).
But what's important: such attempt must be sided with re-assessing the pertinence of the usage of the information systems, and yes, it will annoying and much less comfy and that MUST be acknowledged before even trying.
And big tech is not the only one trying hard to do vendor and developer lock-in.
xOvni|8 months ago
> usually a good way to deal with it is to only use a very simple but coherent subset and enforce this usage with validation tools
You’re right, that’s exactly what we do. We support a growing subset of HTML and CSS that’s documented. We also use the W3C testing suite for HTML/CSS, and PDF validators, on top of custom unit tests.
> And big tech is not the only one trying hard to do vendor and developer lock-in.
We "only" follow open specifications and refuse vendor-specific features to avoid lock-ins (equivalent closed-source tools love that). And we even love the other open-source "concurrents": ♥ to Paged.js and Vivliostyle, try them, they’re great too!
sodimel|8 months ago
henrebotha|8 months ago