[Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
Hello Dominik, PoDoFo maintainers, contributors and users,
I'm happy to announce that after other months of strong development
pdfmm, the PoDoFo fork I talked about last year, reached its first tagged
release 0.9.20. The big list of changes[1] is comprensive of the changes
of the first announce[2] together with latest features that I will summarize
below:
- A new PdfDynamicEncoding class has been added and set as the default
encoding in font creation. The dynamic encoding is a CID encoding that
gets built automatically when encoding strings. That is: Unicode
characters are automatically mapped to arbitrary CID characters and a
valid /ToUnicode map is created in the font when embedding. This mean
you can just do painter.DrawText("Unicode string АБВГДЕЁ", x, y) and
forget about picking or building a right PdfEncoding for the font.
Beware: this doesn't yet mean full text shaping/ligatures support, but
it's a big step in the right direction for supporting more complex scripts,
such as arabic and asian ones;
- Standard14 fonts coming from PDFium[3] (PDFium is a recent pdf
renderer developed by google) have been bundled, enabling full font
embedding of such fonts;
- A new PdfContentsReader class has been added: this class completely
replaces the old PdfContentsTokenizer (which was removed), providing
Pdf operators recognition and XObject following. This class is going
to be the core tool in building a PDF renderer and other PDF processing
operations;
- C++ move semantics has been added to most core classes
(PdfVariant/PdfObject/PdfArray/PdfDictionary), allowing to improve
performance in parsing indirect objects and page contents. I don't
have measurements but this effectively halved the timings of my test
suites. A lot other of micro optimizations appear to be possible following
this move;
- PDF/A preservation: the original PoDoFo library is not able to
manipulate a PDF/A compliant file without loosing this compliance.
pdfmm is now able to perform saves/incremental saves preserving the
compliance (that is: updating the XMP metadata and respecting some
serialization restrictions of PDF/A);
- The automatic unit tests have been restored and a full-fledged
continuous integration for Windows, linux and mac has been implemented
using on github actions[4];
- A playground area with full set of static dependencies built for
Win64, macos-x86_64, linux-x86_64 has been prepared[5]. While the
dependencies will comes without warranty, this makes testing/developing
pdfmm completely hustle-free;
- A lot of bug fixes and other things that I forget about, just look the
changelog and git commit descriptions.
While I still somehow don't recommend anyone to use pdfmm until I
settle the API review (something that I plan to do together with other tasks
before this summer in a 0.10.x release[6]) and assuming the C++ PDF
manipulation user base to be quite small, I begin to think that pdfmm
won't be ignored for much longer. pdfmm is at least 1 man year worth of
work ahead of PoDoFo and represents a solid improvement in features
and API quality, with a very little set of features dropped (only the broken
PDF linearization support has been removed and Type1 font subsetting
is temporarily disabled) and while I noticed a couple of interesting
PoDoFo 0.9.x patches emerging (stack guards and modern encryption
protocols) I doubt anyone at this point is really doing the same kind
of active development I am pushing into pdfmm (or at least nobody talk
about it openly in the PoDoFo mailing list). I thought a lot about my
relationship with the PoDoFo project in these months and while I like to
work without constraints and still aim to push for my vision of what
a modern C++ PDF manipulation should be, I am concerned that this
work may not settle in the long run. Convinced by zyx's openings in a
recent discussion[7] I offer the community to merge back this work to
PoDoFo. I am going to do this work at some conditions, which should be
seen more as a concrete plan of action:
1) PoDoFo project should be split in two different subprojects,
one covering the library and unit tests, one covering the tools.
I will initially maintain the new library and test code, and keep this
role until the I feel a good fit for the role and the community is
comfortable with my work. Other people should take a step forward and
show interest in porting the PoDoFo tools, which I will not maintain
as a whole (I can port/maintain one or two). The old PoDoFo 0.9.x
codeline will be branched and maintained separately by current people;
2) pdfmm should be accepted as a whole replacement of the PoDoFo
library and test code, that will converge to a 1.0 release. pdfmm name
references will be renamed back to PoDoFo before the move. Also
PoDoFo 0.9.x latest commits will be merged to the new PoDoFo 1.x.y
series (pdfmm is already currently in sync with SVN trunk). Some
commits/patches will not be merged because unnecessary or the same
features can be obtained in new ways. I am **not**
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
Hi Francesco,
First of all, congratulations on the release and thanks for all the
information.
I will go through your notes and also other mails, but wanted to give you
some feedback at first.
Kind regards,
Dominik
On Sat, Feb 12, 2022 at 7:16 PM Francesco Pretto wrote:
> Hello Dominik, PoDoFo maintainers, contributors and users,
>
> I'm happy to announce that after other months of strong development
> pdfmm, the PoDoFo fork I talked about last year, reached its first tagged
> release 0.9.20. The big list of changes[1] is comprensive of the changes
> of the first announce[2] together with latest features that I will
> summarize
> below:
>
> - A new PdfDynamicEncoding class has been added and set as the default
> encoding in font creation. The dynamic encoding is a CID encoding that
> gets built automatically when encoding strings. That is: Unicode
> characters are automatically mapped to arbitrary CID characters and a
> valid /ToUnicode map is created in the font when embedding. This mean
> you can just do painter.DrawText("Unicode string АБВГДЕЁ", x, y) and
> forget about picking or building a right PdfEncoding for the font.
> Beware: this doesn't yet mean full text shaping/ligatures support, but
> it's a big step in the right direction for supporting more complex scripts,
> such as arabic and asian ones;
> - Standard14 fonts coming from PDFium[3] (PDFium is a recent pdf
> renderer developed by google) have been bundled, enabling full font
> embedding of such fonts;
> - A new PdfContentsReader class has been added: this class completely
> replaces the old PdfContentsTokenizer (which was removed), providing
> Pdf operators recognition and XObject following. This class is going
> to be the core tool in building a PDF renderer and other PDF processing
> operations;
> - C++ move semantics has been added to most core classes
> (PdfVariant/PdfObject/PdfArray/PdfDictionary), allowing to improve
> performance in parsing indirect objects and page contents. I don't
> have measurements but this effectively halved the timings of my test
> suites. A lot other of micro optimizations appear to be possible following
> this move;
> - PDF/A preservation: the original PoDoFo library is not able to
> manipulate a PDF/A compliant file without loosing this compliance.
> pdfmm is now able to perform saves/incremental saves preserving the
> compliance (that is: updating the XMP metadata and respecting some
> serialization restrictions of PDF/A);
> - The automatic unit tests have been restored and a full-fledged
> continuous integration for Windows, linux and mac has been implemented
> using on github actions[4];
> - A playground area with full set of static dependencies built for
> Win64, macos-x86_64, linux-x86_64 has been prepared[5]. While the
> dependencies will comes without warranty, this makes testing/developing
> pdfmm completely hustle-free;
> - A lot of bug fixes and other things that I forget about, just look the
> changelog and git commit descriptions.
>
> While I still somehow don't recommend anyone to use pdfmm until I
> settle the API review (something that I plan to do together with other
> tasks
> before this summer in a 0.10.x release[6]) and assuming the C++ PDF
> manipulation user base to be quite small, I begin to think that pdfmm
> won't be ignored for much longer. pdfmm is at least 1 man year worth of
> work ahead of PoDoFo and represents a solid improvement in features
> and API quality, with a very little set of features dropped (only the
> broken
> PDF linearization support has been removed and Type1 font subsetting
> is temporarily disabled) and while I noticed a couple of interesting
> PoDoFo 0.9.x patches emerging (stack guards and modern encryption
> protocols) I doubt anyone at this point is really doing the same kind
> of active development I am pushing into pdfmm (or at least nobody talk
> about it openly in the PoDoFo mailing list). I thought a lot about my
> relationship with the PoDoFo project in these months and while I like to
> work without constraints and still aim to push for my vision of what
> a modern C++ PDF manipulation should be, I am concerned that this
> work may not settle in the long run. Convinced by zyx's openings in a
> recent discussion[7] I offer the community to merge back this work to
> PoDoFo. I am going to do this work at some conditions, which should be
> seen more as a concrete plan of action:
>
> 1) PoDoFo project should be split in two different subprojects,
> one covering the library and unit tests, one covering the tools.
> I will initially maintain the new library and test code, and keep this
> role until the I feel a good fit for the role and the community is
> comfortable with my work. Other people should take a step forward and
> show interest in porting the PoDoFo tools, which I will not maintain
> as a whole (I can port/maintain one or two). The old PoDoFo 0.9.x
> codeline will be branched and maintained separately by current people;
> 2) pdfmm should
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
Hi, I'm not the decision maker here, but I understood you'd like my opinion on the matter too, I guess because I help with the pending patches (eeks, I track several patches on this mailing list to be "reviewed"/committed), even my review skills are pretty bad. On Sat, 2022-02-12 at 19:16 +0100, Francesco Pretto wrote: > 1) PoDoFo project should be split in two different subprojects, > one covering the library and unit tests, one covering the tools. While I understand your reason behind this, I'd rather not split it. See the PoDoFo Browser state (it required updates after API changes in PoDoFo, but it was unnoticed, because it's out of the PoDoFo project itself). Better to keep the tools together with the library, thus they stay in sync with the library itself (as least can compile). > 2) pdfmm should be accepted as a whole replacement of the PoDoFo > library and test code, that will converge to a 1.0 release. I agree, once the dust settles the 1.0 release can be done. > 3) PoDoFo development is moved without further doubts to a modern > git based development platform such as github/gitlab/... I feel kind of sentiment with the Source Forge, but I also agree there are better tools these days. Being it just about git, Source Force can do it too, but there are more benefits with GitHub/GitLab, like CI/CD, as you mentioned. My personal preference would be GitLab, but it's really just the personal preference, because I work with it more. You've things up and running on GitHub, thus it can be it too. > 4) As soon as the the new development platform is defined and set up, > the old SourceForge web site begins to inform of the existence of the > new platform. Sure, it's just about the web page, which can stay on the Source Forge, together with the mailing list. Again, this is only my personal opinion. As you can see, your proposal sounds good to me. Bye, Milan 'zyx' Crha ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Sun, 20 Feb 2022 at 19:05, zyx wrote: > but I understood you'd like my opinion > on the matter too, I guess because I help with the pending patches > (eeks, I track several patches on this mailing list to be > "reviewed"/committed) > That's very helpful maintenance work that will always be welcome. I still don't know if I will be able to do patches review in a timely manner, we'll see. As I explained several times I am more into active development with my priorities. > > 1) PoDoFo project should be split in two different subprojects, > While I understand your reason behind this, I'd rather not split it. I understand your point. But I state that I'm not currently unavailable to port PoDoFo tools to the new API, also because I don't use them so I would not be the right person to test if they still work or not. Also there's a licensing problem: tools (and tests) are GPL. This basically makes sourcing code from them into the library impossible, even if may possibly make sense. I'm very uncomfortable with this: if tools are in the same repository they should be the same license of the library, to not create such problems. Please also have a look to my proposal to relicense PoDoFo to (slightly) more permissive terms[1]. > My personal preference would be GitLab, but it's > really just the personal preference, because I work with it more. I think GitLab is a very good platforms too, but I also think that GitHub will give us a little bit more visibility, which is also important for an undermanned project like PoDoFo. > Sure, it's just about the web page, which can stay on the Source Forge, > together with the mailing list. > Sure. > Again, this is only my personal opinion. As you can see, your proposal > sounds good to me. > Thank you, I appreciate it. Cheers, Francesco [1] https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04719.html ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Sun, 2022-02-20 at 22:04 +0100, Francesco Pretto wrote: > Also there's a licensing problem: tools (and tests) are GPL. > This basically makes sourcing code from them into the library > impossible Hi, I do not think so. It's very common to have different parts of the code base licensed under different terms. There's nothing wrong about that. It's not only about the code, for example the user documentation is under different license than the source code itself. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Mon, 21 Feb 2022 at 08:53, zyx wrote: > > On Sun, 2022-02-20 at 22:04 +0100, Francesco Pretto wrote: > > Also there's a licensing problem: tools (and tests) are GPL. > > This basically makes sourcing code from them into the library > > impossible > > I do not think so. Maybe I was not clear enough, I will make an example. Some time ago I wanted to make a text extraction API: I looked at podofotxtextract[1] but tools are GPL so I could not just copy from there. Luckily enough podofotxtextract was quite simplistic/limited, but the point is clear: if I want to make turn a tool into an API, for the benefit of everybody, I can not because that would be move GPL into LGPL which is license incompatible (the other way is fine). > It's very common to have different parts of the code > base licensed under different terms. There's nothing wrong about that. There's nothing wrong, but this doesn't mean it's always convenient. For example test code: they are just snippets of code mostly using PoDoFo library in the right way. What's the rationale of enforcing copyleft (GPL) for such code? From my point of view, such code should be to most permissive license as possible, to the point of marking it clearly "public domain", so everybody just feel free to verbatim copy from it. > It's not only about the code, for example the user documentation is > under different license than the source code itself. Sure. But documentation is often licensed in different terms because source code license terms mostly don't apply with the nature of documentation. [1] https://sourceforge.net/p/podofo/code/HEAD/tree/podofo/trunk/tools/podofotxtextract/TextExtractor.cpp ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Mon, 2022-02-21 at 09:24 +0100, Francesco Pretto wrote: > if I want to make turn a tool into an API, for the benefit of > everybody, I can not because that would be move GPL into LGPL which > is license incompatible (the other way is fine). Hi, I see, thanks for the clarification. I agree it makes sense to relax the licenses on the tools too, if the licenses will be changed in the future. Extracting the tools into a separate project won't change anything on the arguments you provided. For a simplicity of the project maintenance it still makes sense to keep them together, from my point of view. You mentioned that you cannot properly test the tools, that it's one of the (other) reasons you'd like to split the tools out of the project. I do not ask you to maintain the tools, especially their functionality, the unit tests are there to test the PoDoFo code. If the tools have bugs, then the tools can be fixed. That's fine. Knowing that the tools can be compiled when the core library API changes is an essential thing, which can be achieved for free, just by keeping them in the same code base. > But documentation is often licensed in different terms because > source code license terms mostly don't apply with the nature of > documentation. Yeah, that was my main point, a little hidden in the paragraph. There are cases where different parts cannot use the same license. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Mon, 21 Feb 2022 at 11:25, zyx wrote: > For a simplicity of the project > maintenance it still makes sense to keep them together, from my point > of view [...] Knowing that the tools > can be compiled when the core library API changes is an essential > thing, which can be achieved for free, just by keeping them in the same > code base. > Actually I agree with your point about simplicity. If people are more comfortable to know that tools can just be compiled with the new API of course I may evaluate do a last effort to port them, so they can still reside in the same repository. After a quick fly by, most are trivial, with the exceptions of podofosign and podofoimpose. It's a mechanical work and obviously at this time I know the API better. If I do the port work, I will not resist to normalize the coding style and reduce the use of C style programming as well ;) . Please understand that after the port I would still need to "recruit" people to ensure they actually work as intended. In short words: they need a maintainer who cares about them. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Mon, 2022-02-21 at 12:17 +0100, Francesco Pretto wrote: > Please understand that after the port I would still need to "recruit" > people to ensure they actually work as intended. In short words: they > need a maintainer who cares about them. Hi, sure, that's fine. As far as I can tell, it's no change from the current state. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
Hi Zyx, Hi Francesco, I also wanted to continue this discussion. Sorry again for the long delay. If you prefer, we could also have a phone/video chat about these points (also whoever is interested could join in). >From my point of view, the most important points/next steps are as follows (feel free to correct me if I am wrong): 1) Decision on splitting PoDoFo and PoDoFo Tools: I would prefer to keep them in the same repository to make sure they are in a buildable state all the time and can also be used as examples for working with PoDoFo. @Francesco Pretto : It would be great if you could take the additional effort and port them to pdfmm. The diff could also be a nice migration guideline for the future. 2) Decision on license of PoDoFo Tools: PoDoFo Tools are currently GPL whereas the library itself is LGPL. This e.g. makes it hard to copy from tools to the library. From my point of view, we should align the license so that the tools have the same license as the library (currently LGPL, for the future see separate discussion). 3) Merging back pdfmm in podofo / replacing podofo with pdfmm: I would agree to the proposal from Francesco here. We should do one last release of PoDoFo 0.9.8 based on the current svn trunk and then replace it. @Zyx: When would be a good point of time for this? Can I just bundle a trunk, do quick tests and upload it? I am not sure about the current state. 4) Move to Git: Yes, let's move to Git* and keep website, mailing list on sourceforge. 5) relicensing to MPL: I am in general open to that, but let's keep discussion in separate mail thread. Best regards, Dominik On Tue, Feb 22, 2022 at 9:39 AM zyx wrote: > On Mon, 2022-02-21 at 12:17 +0100, Francesco Pretto wrote: > > Please understand that after the port I would still need to "recruit" > > people to ensure they actually work as intended. In short words: they > > need a maintainer who cares about them. > > Hi, > sure, that's fine. As far as I can tell, it's no change from the > current state. > Bye, > zyx > > > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Friday, 08.04.2022 at 15:38 +0200 Dominik Seichter via Podofo-users wrote: > Hi Zyx, Hi Francesco, Hi Dominik, hi zyx, hi Francesco, > > I also wanted to continue this discussion. Sorry again for the long > delay. If you prefer, we could also have a phone/video chat > about these points (also whoever is interested could join in). firstly, I'm sorry for not posting for so long, I had so much to do IRL in the meantime. As there seem to be times of change ahead for PoDoFo, I'd like to assume an active role in the project again. > > From my point of view, the most important points/next steps are as > follows (feel free to correct me if I am wrong): > > 1) Decision on splitting PoDoFo and PoDoFo Tools: > I would prefer to keep them in the same repository to make sure they > are in a buildable state all the time and can also be used as > examples for working with PoDoFo. Seconded. > @Francesco Pretto : It would be great if you could take the > additional effort and port them to pdfmm. The diff could also be a > nice migration guideline for the future. > > 2) Decision on license of PoDoFo Tools: > PoDoFo Tools are currently GPL whereas the library itself is LGPL. > This e.g. makes it hard to copy from tools to the library. From my > point of view, we should align the license so that the tools have the > same license as the library (currently LGPL, for the future see > separate discussion). I always understood this difference as having a purpose (in my view, warning people off taking PoDoFo tools and making something non-free out of them). > > 3) Merging back pdfmm in podofo / replacing podofo with pdfmm: > I would agree to the proposal from Francesco here. We should do one > last release of PoDoFo 0.9.8 based on the current svn trunk and then > replace it. > @Zyx: When would be a good point of time for this? Can I just bundle > a trunk, do quick tests and upload it? I am not sure about the > current state. Especially @Dominik: IIRC (I've lurked here in the meantime and looked in the issue tracker on SourceForge a few times), there are some patches still outstanding which I'd like to test (using some "poor man's CI/test automation" locally most likely) and then apply to SVN trunk, which fix security issues/crashers, so that I'd be grateful for considering them necessary for the next release. I'm not currently doing other work (a day job), so I think I can do this quickly, I hope starting tomorrow (Sunday). For the other issues labeled "security" I'd also like to see what I can do (I hope to produce patches and then handle them like the others, could you please do too?). > > 4) Move to Git: > Yes, let's move to Git* and keep website, mailing list on > sourceforge. Yes (after next release, I hope, if I'll succeed in committing with my mabri SourceForge user account). Issues which won't be copied to the new version control hosting (to enable further work on them, after the move, if the new issue tracker also has such features as e.g. issue states, besides open/closed, the SourceForge one has) should be closed at SourceForge, of course (IMHO at least). > > 5) relicensing to MPL: > I am in general open to that, but let's keep discussion in separate > mail thread. I think I'd like to think/discuss more about that (at least it's copyleft?), in its mail thread. > > > Best regards, > Dominik Best regards, mabri > > > > > On Tue, Feb 22, 2022 at 9:39 AM zyx wrote: > > On Mon, 2022-02-21 at 12:17 +0100, Francesco Pretto wrote: > > > Please understand that after the port I would still need to > > "recruit" > > > people to ensure they actually work as intended. In short words: > > they > > > need a maintainer who cares about them. > > > > Hi, > > sure, that's fine. As far as I can tell, it's no change from the > > current state. > > Bye, > > zyx > > > > > > ___ > > Podofo-users mailing list > > Podofo-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/podofo-users > ___ > Podofo-users mailing list > Podofo-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/podofo-users ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Fri, 8 Apr 2022 at 15:38, Dominik Seichter wrote: > I also wanted to continue this discussion. Sorry again for the long delay. If > you prefer, we could also have a phone/video chat about these points (also > whoever is interested could join in). > I will try to facilitate the chances to have a virtual meeting among PoDoFo maintainers/contributors to know each other and take some decisions. I created a form where interested people can specify some preferences about this meeting (like preferences for working days or weekends). If there's enthusiasm enough I can move on and create a doodle to find an exact day. The link for the form is: https://docs.google.com/forms/d/e/1FAIpQLSdAQrk_ktmgzJI_eZvevfvAlfG5EsttVftouNO3cfUKT2uUig/viewform?usp=sf_link You told me there was once a freenode irc #podofo channel. Since freenode seems to have been abandoned by open source projects, and IRC is generally definitely less popular in these days, I opened a Discord channel/server, which could also be possibly used for the virtual meeting: https://discord.gg/SAVm4DVN It's possible to join with browser only. > 1) Decision on splitting PoDoFo and PoDoFo Tools: > I would prefer to keep them in the same repository to make sure they are in a > buildable state all the time and can also be used as examples for working > with PoDoFo. > @Francesco Pretto : It would be great if you could take the additional effort > and port them to pdfmm. The diff could also be a nice migration guideline for > the future. > I already began doing it. I will inform you about the progresses soon. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
Hello Matthew, On Sat, 9 Apr 2022 at 23:36, Matthew Brincke wrote: > > 2) Decision on license of PoDoFo Tools: > PoDoFo Tools are currently GPL whereas the library itself is LGPL. This e.g. > makes it hard to copy from tools to the library. From my point of view, we > should align the license so that the tools have the same license as the > library (currently LGPL, for the future see separate discussion). > > I always understood this difference as having a purpose > (in my view, warning people off taking PoDoFo tools and making something > non-free out of them). > As I stated, separate licenses makes harder for all to possibly refactor tools functionalities into APIs, which should be always doable. This is the most convincing argument to me for having a single consistent license for tools and library. I add that tests and example code should be always extremely permissive. > >> 3) Merging back pdfmm in podofo / replacing podofo with pdfmm: >[...] there are some patches still outstanding which I'd like to test (using >some "poor man's CI/test automation" locally most likely) > and then apply to SVN trunk, which fix security issues/crashers, so that I'd > be grateful for considering them > necessary for the next release [...] As I mentioned before, my intention is to merge all latest PoDoFo patches into pdfmm (atm I am just lagging behind few ones) before pushing for a merge back to PoDoFo, with few exceptions for unnecessary ones. Nothing useful should be lost. > > 5) relicensing to MPL: > I am in general open to that, but let's keep discussion in separate mail > thread. > > I think I'd like to think/discuss more about that (at least it's copyleft?), > in its mail thread. > Yes, MPL 2.0 is still copyleft, but it's more permissive with regard to static linking. The thread is still there for discussions, and I invite you to add your opinion as well. I add that the challenge for PoDoFo is to stay relevant in a world where C++ libraries in general are less and less required, and I believe the license issue is also a key factor to keep its relevance in the years coming. Since a relicensing is going to be costly (few details on this coming very soon: I am almost finished with a complete list of all PoDoFo contributors), I asked Dominik if he would consider even more permissive licenses such as Apache/MIT. I'm waiting for his opinions on this on the thread, and I ask you to share your thoughts as well. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Fri, 2022-04-08 at 15:38 +0200, Dominik Seichter wrote: > @Zyx: When would be a good point of time for this? Can I just bundle > a trunk, do quick tests and upload it? Hi, the only leftover patch on the list I had in my to-do was the one I just committed as r2054. I do not watch the issue tracker on the SourceForge page, if there is any patch outstanding I'm not aware of it. It's also possible I lost track of some patches on the mailing list. I've also these two threads in my to-do from January: https://sourceforge.net/p/podofo/mailman/message/37412541/ https://sourceforge.net/p/podofo/mailman/message/37596493/ , but I didn't get to them yet. I do not think anything should be blocked due to them, they can be addressed anytime later. Otherwise I'd say you can create a release when you have a time and/or when mabri finishes the work he promised to do in his mail in this thread. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Sun, 2022-04-10 at 23:29 +0200, Francesco Pretto wrote: > I asked Dominik if he would consider even more > permissive licenses such as Apache/MIT. I'm waiting for his opinions > on this on the thread, and I ask you to share your thoughts as well. Hi, I reply here, because it's not really related to the relicensing as such. I had a quick look on the license information in the pdfmm, which looks like this: /** * Copyright (C) 2007 by Dominik Seichter <> * Copyright (C) 2020 by Francesco Pretto <> * * Licensed under GNU Library General Public License 2.0 or later. * Some rights reserved. See COPYING, AUTHORS. */ I suggest to use a standard form of the copyright notices, thus any existing tools can help to aid any discrepancies in this regard. The SPDX notes are similarly short and easy to decipher. The above would look like: /* * SPDX-FileCopyrightText: (C) 2007 Dominik Seichter <> * SPDX-FileCopyrightText: (C) 2020 Francesco Pretto <> * SPDX-License-Identifier: LGPL-2.0-or-later */ (note of removed "by" and no '/**' at the beginning - it's because '/**' can be understood as a documentation comment for tools generating developer documentation, where these license comments really do not belong to). Also, when it comes to it, the sources can be dual-licensed. There are large/well-known projects doing that. Just for consideration. Bye, zyx ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
Re: [Podofo-users] [RFC] pdfmm 0.9.20 released and offer to merge back to PoDoFo
On Thu, 14 Apr 2022 at 07:52, zyx wrote: > I suggest to use a standard form of the copyright notices, thus any > existing tools can help to aid any discrepancies in this regard. The > SPDX notes are similarly short and easy to decipher. The above would > look like: > > /* > * SPDX-FileCopyrightText: (C) 2007 Dominik Seichter <> > * SPDX-FileCopyrightText: (C) 2020 Francesco Pretto <> > * SPDX-License-Identifier: LGPL-2.0-or-later > */ > > (note of removed "by" and no '/**' at the beginning - it's because > '/**' can be understood as a documentation comment for tools generating > developer documentation, where these license comments really do not > belong to). > Very good suggestion. My intention was of course having shorter, more maintainable headers: this SPDX format seems a better solution, we should adopt it instead. > Also, when it comes to it, the sources can be dual-licensed. There are > large/well-known projects doing that. > Yes, projects can be dual licensed and some notable ones do it but that is usually required in the case of mutually incompatible licenses. For example cairo is dual licensed in LGPL 2.1 + MPL 1.1 because MPL 1.1 is incompatible with LGPL. If you pick a more permissive license which is compatible with LGPL you don't have such issue and the dual licensing may be redundant (MPL2 for example is LGPL compatible). Of course dual licensing could help in case a more permissive license somehow is found to be incompatible with a future version of LGPL but that's something quite hard to even imagine. These comments belong more to the re-licensing thread, let's try to stick to that thread for licensing related discussions. Cheers, Francesco ___ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
