<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>
<blockquote type="cite" class="">
<div class="">On 13 Aug 2019, at 18:11, Thiago Macieira <<a href="mailto:thiago.macieira@intel.com" class="">thiago.macieira@intel.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On Tuesday, 13 August 2019 02:20:04 PDT Shawn Rutledge wrote:<br class="">
<blockquote type="cite" class="">Why are you biased towards Poppler being better?  It’s older, yes, and it<br class="">
has had a Qt binding for a long time, so it has been easy to use in Qt<br class="">
widget-based projects for a long time already.  (I have experience doing<br class="">
that; when I started, Qt was at 4.5.  Porting my application to Qt 5 was<br class="">
easy too.) In casual testing, Pdfium doesn’t seem slower to me.  But it<br class="">
would be worth benchmarking.<br class="">
</blockquote>
<br class="">
Because I don't want to see us undermine a nice open source project that is <br class="">
struggling to find contributors by promoting a worse alternative just because <br class="">
it can be sold.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
Poppler is not usable by any of Qt’s commercial customers, and there’s quite some demand for PDF viewing capabilities.<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">Personally I hope that the two will coexist, and that features being added<br class="">
to one will help to motivate the same features to be added in the other<br class="">
(just as with Firefox and Chromium: we’re all better off because both of<br class="">
them continue to coexist).  <br class="">
</blockquote>
<br class="">
Good, but that assumes that PDFium is actually a good alternative, in terms of <br class="">
RAM consumption and PDF feature support. So far I haven't seen anyone say they <br class="">
have done the comparison of features, ease of build, RAM consumption, etc. <br class="">
between it and Poppler. If this has been done, it needs to be posted. If it <br class="">
hasn't, then here's my -1 until it is done.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
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.<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">When it comes to Qt Quick, either solution can be exposed either as a<br class="">
subclass of QImageIOHandler (so that it “just works” as an image format) or<br class="">
QQuickImageProvider.  <br class="">
</blockquote>
<br class="">
Wait, what? Why would you do it via *image* handlers? Most of PDF is text. Is <br class="">
PDFium and the proposed module capable of selecting text, copy it to the <br class="">
clipboard, show the document structure, etc.?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
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.<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">What I dislike about Pdfium so far is that it has its own raster engine to<br class="">
do the rendering: we can only get fully rendered images out of it so far,<br class="">
not QPainter calls.  It may be that it’s faster or slower than it would be<br class="">
to use QPainter; but either way, it’s a kind of bloat to ship another<br class="">
internal paint engine.  But who knows, if we want to spend the time we<br class="">
might be able to refactor it, depending on whether there is some way to get<br class="">
rendering callbacks out of it.  I haven’t tried to figure that out either. <br class="">
</blockquote>
<br class="">
Indeed, but it might be worth it. We won't know until someone posts the <br class="">
analysis.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
I could very well be wrong, but I vaguely remember that poppler does the same thing.<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
<blockquote type="cite" class="">We have commercial customers who need the basic capabilities that most<br class="">
normal PDF viewers have (a bit beyond displaying an image for each page). <br class="">
I’m working on adding those features, and want to do it in a way that<br class="">
breaks down to reusable Qt Quick components rather than making a monolithic<br class="">
Item for the whole PDF.  Realistically in the future though, we probably<br class="">
will only add features as customers ask for them.  And it seems that KDAB<br class="">
has such customers too, since they have contributed some patches to the<br class="">
qtpdf repo.<br class="">
</blockquote>
<br class="">
Cool. Can you share a bit of the roadmap? What are the features that have been <br class="">
implemented, which ones you do plan on adding anyway and which ones probably <br class="">
need a customer to get behind and push?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
</div>
The code is out there in the qt-labs repo. A quick glance at <a href="https://github.com/qt-labs/qtpdf/tree/dev/src/pdf" class="">https://github.com/qt-labs/qtpdf/tree/dev/src/pdf</a> might give you some idea of the supported features.
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Lars</div>
<div class=""><br class="">
</div>
</body>
</html>