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
