> On 13 Aug 2019, at 02:06, Thiago Macieira <[email protected]> wrote: > > On Monday, 12 August 2019 15:10:47 PDT Kevin Kofler wrote: >> The existing implementation based on PDFium, on the other hand, provides us >> with an alternative implementation, which application developers may prefer >> for various reasons (one of which is licensing, as already pointed out). >> This is an added value that does not already exist elsewhere. And the code >> is already there. It only needs updating for the current PDFium. > > Sure, but again, what are the cons of this? If we promote this module to the > main Qt, it means we are recommending people use it. I'd like to know if > we're > promoting a good alternative. > > If it has lots of problems rendering PDF or consumes lots of RAM or has some > other big drawback, we should either not promote it (keep it as an add-on) or > instead have a big disclaimer telling people to consider Poppler first.
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. 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). I have been wishing for Poppler to acquire my favorite set of PDF editing features for a decade now, but progress seems to be slow, and I haven’t taken the time to become a PDF expert and add them myself. But PDFium has a company behind it, and I have heard that if one pays for the commercial version, it has enough features to make a real PDF editing application. I haven’t tried that yet; but it may turn out later that this will give us access to a bigger feature set eventually, if there is customer demand, and if we can find the time to implement Qt API for those features. 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. Earlier I used Poppler via QQIP; now I want to use QIIOH. Open source applications could choose either one, and we can try to make it easy to switch; but the Qt business interests are more aligned with Pdfium because of its license. I would not mind implementing the same feature set with both back-ends though. 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. And then there’s the JS engine… that needs investigation too. IMO there ought to be a way to configure it to leave that out, but I don’t know if there is yet. 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. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
