10 Years of HexaPDF
gettalong.org
gettalong.org
However, my only major issue with it was the difficulty (back then) for laying out PDFs. Most people I worked with found it a lot easier to layout in HTML/CSS and converting to PDF from there; so we went that way.
If I were to look for a way to manipulate existing PDFs I'd definitely use HexaPDF. I'll re-evaluate its (more recently) improved layout capabilities again and consider it for my next project. And I also think the dual-licensing model is fair.
Congrats on the 10-year/1.0 milestone.
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!
> Normally one would need to pay ISO to get a standards document.
What is the point of a standard that is not pulicly available ?
"Developing, publishing and maintaining ISO standards incurs a cost, and revenues from selling them helps ISO and its members to cover an important part of these costs. Charging for standards allows us to ensure that they are developed in an impartial environment and therefore meet the needs of all stakeholders for which the standard is relevant. This is essential if standards are to remain effective in the real world."
I don't think the PDF standard was developed in an impartial environment.
The above justification might apply to some of their standards but certainly not to PDF.
PDF was developed by Adobe. They make lots money selling PDF tools and licensing PDF software.
PDF didn't have to be a standard. It could be a proprietary format.
Adobe wanted the adoption of PDF so they made PDF a standards so that they can sell more PDF tools.
It didn't have to an ISO standard. Adobe could have released it as an open spec with some sort of permissive license.
Adobe wanted it to be ISO standard to piggy back on "respectability" of International Standards Organization, to buy the impression that it's an open standard.
But ISO makes money by selling standards so we ended up in this situation when the spec for "open" standard that Adobe wants to be adapted costs $100+ to buy.
I guess Adobe at some point figured out this is stupid and made the spec available for free.
I don't know if that's the explanation here (maybe there's good reasons for it?) but it's the first thing that came to mind.
Keep in mind that ISO traditionally dealt more with industrial standards; eg something like https://www.iso.org/standard/40447.html costs ~$180, but I doubt anyone who'd be attempting to compete in the "Apparatus for industrial gamma radiography" world would consider that expense as any more burdensome than buying office consumables.
Chop it down by a factor of 2-4, and the question still remains: is $250 significant compared to the amount of work you're going to have to do to be competitive in the PDF-document processing space?
(for quick hacks, reverse engineering is good enough. you only need the standard once you're processing enough client documents that you need to know all about the long tail of possible but unlikely constructs your code may encounter, after all)
ISO is the international standards organization. A software developer in Indonesia earns $500 per month. Half your salary for one document is indeed a lot.
How much is 500g emping for you all? From a swiss source it's $25. That might give us a rough idea of price differentials...
[This is all moot though, because the PDF standard is available gratis.]
I hear (even for those based in US) that location plays a huge part, but even so, I assume specialization also played a big part?
In a world where I can work almost as easily 12 time zones away as 2, I'm not sure why these huge continental disparities still exist, but they do.
Are there any examples of this? How do you monetize a DLL file? One time purchase and later upgrades?
It seems like you'd have to put it behind an API and charge for usage, though I don't have a good overview of what the other options are.
We paid on a per domain basis and also paid a yearly maintenance fee to get updates. Nothing stopped us from just using the library in ways that violated the license but we didn’t. The threat of lawsuit is an effective deterrent if the ethical concerns aren’t.
In my experience for B2B the people that are going to steal from you were never going to pay anyways.
I used to think that but eventually the evidence pointing to the opposite was overwhelming. It wasn't just small companies either, some of them you will have heard of.
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.
Just either use the code unmodified, or release your modifications to customers, or to the public in general.
Do the businesses buying commercial licenses just not understand the AGPL license? or are their development processes not rigorous enough to ensure compliance? The AGPL includes some easy ways to be forgiven for accidental violations, so that should not be a problem in almost all cases. So only deliberate non-compliance should be an issue.
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...
Also, doing this extra work and developing the binary is probably more expensive than just buying a commercial license.
Typo in the article word imported should be important.