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 <cez...@gmail.com> 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 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** going to
> gradually patch PoDoFo towards the actual state of pdfmm: I
> just don't have time for that and I don't see many advantages in doing
> it either;
> 3) PoDoFo development is moved without further doubts to a modern
> git based development platform such as github/gitlab/... . Minimum
> required features are easy pull-request interface, issue tracker, win-mac-
> linux Continous Integration with submodules support. I'm in favor
> or using github, which I am using in pdfmm, as the chosen platform.
> I'm open to evaluate other options if a person shows some advantages
> over my proposed solution and the same person is able to convert the
> current CI infrastructure, keeping submodule support (I'm not going to
> do this porting work). 0.9.x maintain tasks can continue to happen on
> the SF platform/mailing list;
> 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. Either one person take a step forward and offers to
> create a new basic static website/FAQ for the new-PoDoFo or we go
> without a website at all. In both cases at some point the old SF website
> should be archived. Of course it can stay online indefinitely for
> preservation purposes;
> 5) Last but not least: I ask for a Mozilla Public License re-licensing
> of PoDoFo. This is a very complex topic involving legal/copyright
> matters. I am creating a new thread shortly after to discuss this,
> explaining exactly why I suggest this move. Please, let's discuss
> about this topic in that thread.
>
> I am really sorry for the lengthy post and if my words sounds bossy
> and or/shows little or no room for discussion. I actually truly encourage
> you to review the pdfmm code and say what you really think about it
> and about my offer/plan. I don't want to enforce a takeover of the
> project with a muscular move and if some of you feel it like that then
> it's all my fault as I couldn't suggest better ways to improve the
> development of PoDoFo in the past couple of years. I put no rush,
> but I foresee a window of opportunity later on this summer around August,
> and I would like the discussion to happen (and finish) before that. I will
> consider the plan accepted if Dominik, and PoDoFo more active
> maintainers in the past years, I guess Matthew and Zyx (do you mind
> to reveal us your name :-) ?), agree with it.
>
> Thank you for your attention.
>
> Cheers,
> Francesco
>
> [1] https://github.com/pdfmm/pdfmm/blob/master/CHANGELOG.md
> [2]
> https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04628.html
> [3] https://github.com/mozilla/pdf.js/tree/master/external/standard_fonts
> [4] https://github.com/pdfmm/pdfmm/actions
> [5] https://github.com/pdfmm/pdfmm/tree/master/playground
> [6] https://github.com/pdfmm/pdfmm/blob/master/TODO.md
> [7]
> https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04674.html
>
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
