pp
pp copied to clipboard
Added support of PDF for PlantUML
Better support of PlantUML diagrams in PDF.
Here https://github.com/vasil-sd/plantuml-pdf-math is locates plantuml.jar augmented with libraries for PDF generation and Math typesetting.
Several points must be considered before merging:
- The link to original (and uptodate) Jar files is not provided (
make
should be able to download original files and integrate them to pp) - The documentation must show the licenses of each component integrated in pp (are they all compatible with pp?)
- These dependencies may produce a huge executable. Their integration must be optional.
- Check if the documentation and tests must be updated.
- Binary files (e.g. .jar) must not be stored in the git repository (too huge and not git friendly)
Hi @CDSoft and @vasil-sd!
2. The documentation must show the licenses of each component integrated in pp (are they all compatible with pp?)
Althogh PlantUML used to be GPLv2 (and its sourceforge home page still says so) the actual PlantUML license states that it's now GPLv3:
PlantUML is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
So it doesn't seem that there are licensing problems here, since PP is also GPLv3 (there would be if it was still GPLv2).
3. These dependencies may produce a huge executable. Their integration must be optional.
The file plantuml.jar
is 7.2Mb, so including it wouldn't really lead to a "huge" executable — pandoc, for example, is 66Mb. But probably having PP rely on the user's installed PlantUML is better, as many users might not even need it or would preferr and independenlty updateable version of it.
The problem is not (the original) plantuml.jar but all other JAR files added to plantuml.jar (see https://github.com/vasil-sd/plantuml-pdf-math). Their licenses should be explicitly checked and documented.
Mh, that's a serious problem. Licenses transparency is important.
Better leave it to the user to install PlantUML.
There's even a Chocolatey package for it, which makes it easier for Windows users to install and update PlantUML:
- https://chocolatey.org/packages/plantuml
Maybe you could add a note and a link about optional PP third party tools which are available as Chocholatey packages (other tools beside PlantUML are present, like Diita and others). Chocolatey GUI makes it really easy to install all these small tools and keeping them always updated, instead of having to manually check for new versions and download/install them individually.
- https://chocolatey.org/packages/ChocolateyGUI
Actually, it would be nice to see an official PP Chocolatey package in the future, for the same reasons. Packages are driven by PowerShell scripts, but after creating the first script all updates could be autogenerated via scripts at release time. In theory, the PP Chocolatey package could also install third party tools, by including their Choco package (if present) or by downloading them via Chocolatey API.
I would suggest to use the -plantuml
option to use a custom plantuml.jar instead of embedding dependencies with unknown licenses.