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

[Thiago Macieira]

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.

> 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.

> 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.?

> 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.
 
> 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?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products