[Development] Qt PDF as a new TP module for Qt 5.14

[Lars Knoll]

On 13 Aug 2019, at 18:11, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On Tuesday, 13 August 2019 02:20:04 PDT Shawn Rutledge wrote:
Why are you biased towards Poppler being better?  It’s older, yes, and it
has had a Qt binding for a long time, so it has been easy to use in Qt
widget-based projects for a long time already.  (I have experience doing
that; when I started, Qt was at 4.5.  Porting my application to Qt 5 was
easy too.) In casual testing, Pdfium doesn’t seem slower to me.  But it
would be worth benchmarking.

Because I don't want to see us undermine a nice open source project that is
struggling to find contributors by promoting a worse alternative just because
it can be sold.

Poppler is not usable by any of Qt’s commercial customers, and there’s quite some demand for PDF viewing capabilities.

Personally I hope that the two will coexist, and that features being added
to one will help to motivate the same features to be added in the other
(just as with Firefox and Chromium: we’re all better off because both of
them continue to coexist).

Good, but that assumes that PDFium is actually a good alternative, in terms of
RAM consumption and PDF feature support. So far I haven't seen anyone say they
have done the comparison of features, ease of build, RAM consumption, etc.
between it and Poppler. If this has been done, it needs to be posted. If it
hasn't, then here's my -1 until it is done.

I don’t think we should be blocking valid projects/ideas because of that. In any case, from all I know, PDFium is feature wise competitive. In any case, the qt-labs module already exists, the question was simply whether we should merge it into the web engine module for ease of building and start supporting it.

When it comes to Qt Quick, either solution can be exposed either as a
subclass of QImageIOHandler (so that it “just works” as an image format) or
QQuickImageProvider.

Wait, what? Why would you do it via *image* handlers? Most of PDF is text. Is
PDFium and the proposed module capable of selecting text, copy it to the
clipboard, show the document structure, etc.?

I think this was meant as an additional way to expose it. If you’d looked at the existing qt-labs module, you’d see that this provides a decent API, not just an image provider.

What I dislike about Pdfium so far is that it has its own raster engine to
do the rendering: we can only get fully rendered images out of it so far,
not QPainter calls.  It may be that it’s faster or slower than it would be
to use QPainter; but either way, it’s a kind of bloat to ship another
internal paint engine.  But who knows, if we want to spend the time we
might be able to refactor it, depending on whether there is some way to get
rendering callbacks out of it.  I haven’t tried to figure that out either.

Indeed, but it might be worth it. We won't know until someone posts the
analysis.

I could very well be wrong, but I vaguely remember that poppler does the same thing.

We have commercial customers who need the basic capabilities that most
normal PDF viewers have (a bit beyond displaying an image for each page).
I’m working on adding those features, and want to do it in a way that
breaks down to reusable Qt Quick components rather than making a monolithic
Item for the whole PDF.  Realistically in the future though, we probably
will only add features as customers ask for them.  And it seems that KDAB
has such customers too, since they have contributed some patches to the
qtpdf repo.

Cool. Can you share a bit of the roadmap? What are the features that have been
implemented, which ones you do plan on adding anyway and which ones probably
need a customer to get behind and push?

The code is out there in the qt-labs repo. A quick glance at https://github.com/qt-labs/qtpdf/tree/dev/src/pdf might give you some idea of the supported features.

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190813/4d39e03a/attachment.html>