I was excited to hear about a PDF library not based on iText but alas, this is just another iText fork, in fact the full fork chain seems to be:

    LibrePDF/OpenPDF 
    forked from rtfarte/OpenPDF
    forked from kulatamicuda/iText-4.2.0
    forked from daviddurand/iText-4.2.0
    forked from ymasory/iText-4.2.0

I had that same frustration this week. Trying to generate geotiffs from arrays in Python. I found four libraries, all of which just wrap GDAL, all of which have the same quirky issues. Alas. :)

If you have a 1:1 mapping between array cells and pixels (no geographic transformations), just use any image format as intermediate. But I am interested what quirky issues you encountered. I found rasterio very nice to work with using numpy arrays.

Super obscure issues. When I try to use GDAL to build a geotiff from a bumpy array I get an underlying c++ crash of some sort. I'm not an expert. But it happens only when I try to do it within QGIS. It's something about the compatibility of numpy and gdals underlying c++ APIs.

I wish I was smarter and could debug further. Issue doesn't happen standalone but happens in a qt5 plugin for GDAL. I was hoping to find any other implementation of array to tiff in order to avoid this crash. Alas.

Is it possible to create a small test case that removes any proprietary data so it can be sent as a bug report?

Could you share code and data for a minimal crashing example? This sounds like the developers would be glad to fix it. Both GDAL and QGIS have very active devs.

tried this outside of QGIS? pip install rasterio, etc.

We heavily use GDAL/rasterio/numpy at work with no real problems.

Everything works outside QGIS. There's just something about the environment. I have 7 lines of code that crashes my QGIS every time.

Please share those for investigation!

You're a genuis to me. Didn’t know any of this. Good luck.

Is there a place, like Groklaw's UNIX timeline, where you can see which software is derived from what?

If you’re after an open source PDF library in Java, check out Apache PDFBox. It’s actively maintained and has a ton of features.

http://pdfbox.apache.org

Would recommend!

Used PDFBox a couple of projects ago. It was great! Very nice API, works like a charm.

I encountered PDFBox for the first time last week and although it looks promising I was discouraged by the lack of documentation. Was there something you found particularly useful, or should I just start browsing the source? Thanks!

Yeah, current docs might not be the best, I think they are still working on it.

API was pretty intuitive, plus some googling and reading stackoverflow. And yes, browsing the source. I don't remember encountering any major problems with it.

how is OpenPDF vs PDFBox ?

And verapdf

> Open source industry supported PDF/A validation maintained by the Open Preservation Foundation

https://github.com/verapdf

in order to save others the search

Why is this being upvoted now? People have been forking iText for years, ever since the license was changed to AGPL. This repo doesn't even look very active and the last release was last year.

People just can't stand the idea of writing a Forth parser, I guess lol

https://www.prepressure.com/postscript/basics/history

FORTH is a wonderful language, I've written a couple of toy implementations. I just wish I could use it for something "real".

There's an arduino-compatible forth stack, avrforth.

It does require that you license code which runs on it as GPL, which I consider onerous. But it works! If that constraint suits you.

Same here! https://github.com/pmarreck/elixir-snippets/blob/master/rpn_... I found it fun, and it was actually super easy to implement a stack-based language interpreter in an immutable pattern-matching language like Erlang/Elixir.

It's incomplete because I haven't yet figured out how to define the defining character ":"...

Back in the C64 days there was a Abacus Forth but it cost was pretty high if I remember right $225???? I got a copy from the software store I work with as a teenager and got one at cost. It was great after coming from basic > assembly (Talk about your learning curves).

Pdf is a bit more than a forth implementation. There is a reason there are so few pdf parsers out there.

I understand. Was (mostly) joking.

Is the LGPL part of the license actually LGPL 2+, 2.1+ or 3.0+?

At least some of the file headers say 2+, the readme says 3.0+, but this note was added after the fork, with commit https://github.com/daviddurand/iText-4.2.0/commit/312abf7b12... so it may be in error?

If it was in error, does this affect any merged code pieces/PRs submitted/merged after the readme was changed, or do the license headers per-file take precedence?

I have some experience with iText, so possibly I can answer. iText never released a version 4.2.0 for Java. The original forker misunderstood iText versioning and used the number of the C# version. At the time, iText versions for Java were 2.x, and C# were 4.x The code in the forked version is actually the last release of the Java version of iText 2.x, which was the last Java release under the LGPL/Mozilla license.

Thankfully, iText later coordinated release numbers for both platforms to 5.x numbering when they changed the license to AGPL.

So, you should be safe using this version of iText under LGPL or Mozilla, but it's a fairly old release of the library. If you're just using iText for your hacking projects, you're probably better off going with a more recent version.

I hope somebody makes an Eclipse plugin out of this, and integrates it into the TeXlipse LaTeX IDE. It is a sad state of affairs that this aging project (last release was in 2011) is still the most versatile TeX editing environment. For example, it is the only one that I am aware of, beyond command-line editors, that that lets you open up an arbitrary number of views of the same file, which is often needed in large TeX projects. Its current PDF viewer (Pdf4Eclipse) is broken on Hi-DPI displays.

LibreOffice Draw does a nice job at editing PDF files as well

Where is the documentation?

Can this convert a html/css document to PDF? or is chrome headless(ignoring overhead) the way to go these days?

Flying Saucer would do

https://github.com/flyingsaucerproject/flyingsaucer

For more controlled results you could use Prince.

to some extent - using com.lowagie.text.html.simpleparser.HTMLWorker (more like if you have really simple html and css, you can generate a PDF doc out of those - which works well for various reports).

Although if you are looking to convert real web pages to PDF, then this is not a good choice.

Prince (commercial) is outstanding, and supports a wide array of issues specific to printed media.

$495 for desktop license and $3800 for server. I would love to have something this for the times I could use it, but realistically that’s only once or twice per year.

I feel the same way about Adobe’s Creative suite subscription. I use it’s unique capabilities about once every 6 months. I wish there was a one week license.

Does it support Unicode in PDF forms? Feature that poppler still lacks (in 2018!).

How well does it handle merging PDFs? I’ve not found an efficient way for merging many small PDFs in pdfbox/itext without cranking up memory settings.

That so bad about AGPL, that require a fork?

Imagine this scenario. You want to write your own code ProductX and link it with some GPL code. This brings ProductX also under the GPL license.

You can put ProductX on a server and never actually distribute ProductX to anyone. By not distributing ProductX, you don't have to distribute the ProductX source code to anyone -- although technically it IS under the GPL. Since you're not distributing the binary, you don't have to distribute the source. Yet the public can interact with your server and make use of ProductX's services.

The AGPL prevents that. If you write your code ProductX and link it with AGPL code, then ProductX comes under the AGPL license. But now, merely letting the public interact with ProductX on a server requires you to distribute the AGPL source code to ProductX. Now anyone else has the ProductX source code and can compete with you.

The AGPL is also a way for the author of an AGPL library to make money. A library such as iText. If you want to use iText with a proprietary ProductX, then you need to buy a separate commercial license for iText.

If the developer's intent in ProductX is to keep the source code private, then the developer cannot link ProductX with any AGPL licensed code such as iText -- unless the developer is willing to pay for a commercial license to iText.

A developer should never have code that they didn't write themselves, such as a library, unless that library is under a license that the developer can always remain in full compliance with. That includes proprietary and commercial libraries as well as open source libraries. While AGPL is "open source" if you cannot comply with the terms, then don't use it.

Finally, avoid any code you find on the internet that has "no license". If you use such code, the copyright owner of that code could sue you for copyright infringement. "But wait!" they say. "I would never sue anybody, I just want as many people as possible to use my code, so I don't put it under any license." I say: If you're not going to sue me, then put that promise in writing. it's called a license. If you're such a good guy and aren't going to sue me, then put it in writing like all other open source licensed code.

Thanks for the explanation! Does anyone actually release code due to this license (which they wouldn't have released otherwise)? I'd imagine generally if a commercial developer saw a license like that they would just choose not to use the AGPL code. I know I won't use any code or libraries which place these sorts of obligations on me as a developer, unless it's in a product that I was planning to release the source of anyway.

If a commercial developer saw a license like that... they could pay for a commercial licence. Presumably a commercial developer thinks software is worth paying for.

> if a commercial developer saw a license like that they would just choose not to use the AGPL code.

Except for the server bit, the restriction being described is called copyleft. And it appears in all GPL licenses, except LGPL. Some of the major OSS in use today is released under it: Linux, MySQL and MariaDB, VLC, and of course all the FSF software, such as GCC.

I believe it would abligate the developer to release the server side code that uses the library.

The AGPL is an interesting idea in principle, but it is an ecosystem-level coordination problem if you apply it to libraries. Application that include those libraries also need to be AGPL which means any existing application that wants to use it must be re-licensed to AGPL and only use libraries that are AGPL-compatible. Nobody wants to be a first mover in that direction.

Plus it is untested in court just how far its provisions go.

Why the fork? ... oh LICENSE change

Took a glance at this one not so long ago - quite a nice tool to auto-generate PDF docs yet not that good at editing. For such a purpose I still use this PDFfiller https://w9.pdffiller.com but it's a paid one and written in JS. Nevertheless it's well-crafted enough to do all the works on visuals and overall layout