Allow to print pdf doc directly into a QPrinter
Needs RevisionPublic

Authored by sander on Sep 23 2017, 5:35 AM.

Details

Reviewers
aacid
rkflx
Group Reviewers
Okular
Summary

This is the 'official' Qt way of printing. It avoids the conversion of pdf files to postscript that we do currently, and may fix a certain number of printer settings bugs. For example, greyscale printing now works for me, which it never did before.

There is a big caveat to this approach, however: Rendering a pdf doc into a QPrinter object only works with the poppler 'Arthur' backend. While that backend works okay on many documents, it is still lacking important features, and you may see rendering problems. For the most part this is not a fundamental problem. Somebody just needs to sit down and write the missing parts.

For this reason, CUPS printing remains the default, and Qt printing is simply a new option. Additionally, I tagged this option as 'experimental' in the GUI.

Unlike for CUPS printing, Qt printing prints on the entire page and does not scale to the printable area yet. This is only because it is the easiest way. I plan to implement a few standard scaling methods in a subsequent patch, which will only be a few additional lines of code.

Diff Detail

Repository
R223 Okular
Lint
Lint Skipped
Unit
Unit Tests Skipped
sander created this revision.Sep 23 2017, 5:35 AM
Restricted Application added a project: Okular. · View Herald TranscriptSep 23 2017, 5:35 AM
aacid added a subscriber: aacid.Sep 23 2017, 10:15 AM

Using QPrinter may be "official Qt", but that doens't mean better.

you and me know Arthur backend sucks, so i don't see this being of any use to the users.

Why not simply finish the pdfprintpdf branch as i've suggested a few times already?

Using QPrinter may be "official Qt", but that doens't mean better.

That depends on how you look at it. The patch gives you fast printing without conversion to postscript. It is completely platform-agnostic, so there is no fiddling with lpr parameters anymore, and you get printing on Windows for free. Implementing standard scale modes that people have been asking about becomes very easy: see my follow-up patch at https://phabricator.kde.org/D7962 .

you and me know Arthur backend sucks, so i don't see this being of any use to the users.

Yes, the problems with Arthur are known to me: I wouldn't say that it 'sucks' (that probably depends on the type of documents you are wont to use), but it definitely needs more work. But improving Arthur is easy: you have seen me do it. The alternative is to keep fighting with CUPS, which means lots of bugs that only happen in certain hardware/driver configurations, which nobody else can reproduce. Then, lpr doesn't seem to have the level of control that stuff like https://phabricator.kde.org/D7962 requires. Finally, how will you deal with printing on Windows? Do you really want to insert Windows-specific printing code into okular? Who's going to maintain that?

That being said, I understand that you don't want to expose Arthur to end-users today. Then please tell me (honest question!): what specific issues to you want to see fixed in Arthur to make it not suck anymore?

Why not simply finish the pdfprintpdf branch as i've suggested a few times already?

Because I don't see how you can get the flexibility that the QPrinter approach gives you with the approach taken in that branch.

Using QPrinter may be "official Qt", but that doens't mean better.

That depends on how you look at it. The patch gives you fast printing without conversion to postscript. It is completely platform-agnostic, so there is no fiddling with lpr parameters anymore, and you get printing on Windows for free. Implementing standard scale modes that people have been asking about becomes very easy: see my follow-up patch at https://phabricator.kde.org/D7962 .

you and me know Arthur backend sucks, so i don't see this being of any use to the users.

Yes, the problems with Arthur are known to me: I wouldn't say that it 'sucks' (that probably depends on the type of documents you are wont to use), but it definitely needs more work. But improving Arthur is easy: you have seen me do it. The alternative is to keep fighting with CUPS, which means lots of bugs that only happen in certain hardware/driver configurations, which nobody else can reproduce. Then, lpr doesn't seem to have the level of control that stuff like https://phabricator.kde.org/D7962 requires. Finally, how will you deal with printing on Windows? Do you really want to insert Windows-specific printing code into okular? Who's going to maintain that?

That being said, I understand that you don't want to expose Arthur to end-users today. Then please tell me (honest question!): what specific issues to you want to see fixed in Arthur to make it not suck anymore?

Why not simply finish the pdfprintpdf branch as i've suggested a few times already?

Because I don't see how you can get the flexibility that the QPrinter approach gives you with the approach taken in that branch.

But at least it'll work 😄

Anyhow, it's your time, printing is not something I'm interesting in volunteering my time, people made abundant abuse to me to make clear they didn't appreciate me working on it.

rkflx added a subscriber: rkflx.Sep 28 2017, 11:29 PM

Great work, Oliver. If you want to spend your time on Arthur and make users happy that way, I'm all for it.

Idea: Add a task (or multiple tasks) to the Okular workboard to track all printing and/or Arthur related work (otherwise it's difficult for reviewers to get the full picture, with information scattered in Bugzilla, Reviewboard and Phabricator).

Summary

Please add a test plan for future Diffs, it took me ages to find where I could activate this in the GUI.

I tagged this option as 'experimental' in the GUI.

Having it only in the tooltip is definitely not enough, this should be directly in the combobox. The tooltip could contain additional information (Which features are missing? What rendering problems are expected? Are bug reports / contributions encouraged?). Optionally add a longer "What's this?" help.

improving Arthur is easy: you have seen me do it.

When testing this Diff for the first time, I wanted to give it an "-1" because the text rendering was so bad. Then I discovered your patch to Poppler, which brought massive improvements. Therefore, I would highly recommend to only enable Arthur if Poppler is recent enough (add an #ifdef).

what specific issues do you want to see fixed in Arthur

I took https://arxiv.org/pdf/1708.01455.pdf and printed to a "PDF file" (can be observed in an Arthur based Okular, too):

  • page 20: bad smoothing of scaled raster image
  • page 21: parts of vector (?) illustration missing
  • large filesize (5x), because of letters being vectors instead of fonts (might lead to problems regarding the printer's cpu/memory resources?)

Those are not blockers for this patch, just some issues I found with limited testing already.

generators/poppler/generator_pdf.cpp
80

Add Q_ENUM(PrintBackend)

95

m_printBackend->insertItem(PrintBackend::CUPSBackend, "CUPS");. ← Do it like this everywhere you currently have 0. This way you don't risk mixing up magic numbers all over the code in the future.

96

Remove UNIX only and only show the option on Unix in the first place. However, keep the combobox on Windows even if it only has the QPrinter option (clear communication and useful for users switching between Windows and Linux to not get confused debugging printing issues).

101

i18n everywhere

109

Remove all three lines. Could always be brought back if there were actually multiple options on Windows.

138

…then you can just do return m_printBackend->currentData().value<PrintBackend>();

1116

As you depend on pdfOptionsPage where you already have this check anyway, this could go. Too easy to miss that you always have to change both places. The comment is nice though, just move it to the right place.

1162

Just rename your variable to oldRenderBackend, then the initial comment should suffice and this one could go.

Yes, your work here is much appreciated.

Since this fixes grayscale printing, can you mark it with "BUG: 368758"?

Yes, your work here is much appreciated.

Since this fixes grayscale printing, can you mark it with "BUG: 368758"?

As long as it fixes the issue only (if I understand it correctly) with a non-default and experimental option, I'd suggest to use CCBUG: which adds the commit message but does not close the bug. The bug then will be closed when the main choice works.

Hi guys, thanks for all the feedback. I'll look into it, but the next 10 days will be busy. There are two more Arthur patches submitted and awaiting review.

(nice arxiv paper you are using for testing, btw. :-) )

sander updated this revision to Diff 20606.Oct 11 2017, 3:47 PM

Implement all of Henrik's suggestions.

Hi, thanks again for the review. I just updated the patch to include most of your suggestions.

> I tagged this option as 'experimental' in the GUI.
Having it only in the tooltip is definitely not enough, this should be directly in the combobox. The tooltip could contain additional information (Which > features are missing? What rendering problems are expected? Are bug reports / contributions encouraged?). Optionally add a longer "What's this?" help.

I implemented a longer "What's this" help, but I couldn't make it appear in the GUI. What's the magic button for that?

Therefore, I would highly recommend to only enable Arthur if Poppler is recent enough (add an #ifdef).

Poppler 0.60 or a Windows OS is required now.

I took https://arxiv.org/pdf/1708.01455.pdf and printed to a "PDF file" (can be observed in an Arthur based Okular, too):

page 21: parts of vector (?) illustration missing

A patch for this can be found at https://bugs.freedesktop.org/show_bug.cgi?id=103118

large filesize (5x), because of letters being vectors instead of fonts

Yeah, I know about this one. There's nothing really do be done about this on the Okular side, this is Qt's doing.
On the other hand one could argue that this is what "printing to a file" actually means: you lose all semantic
information like letters, annotations, tags, etc.

(might lead to problems regarding the printer's cpu/memory resources?)

No idea.

large filesize (5x), because of letters being vectors instead of fonts

Yeah, I know about this one. There's nothing really do be done about this on the Okular side, this is Qt's doing.
On the other hand one could argue that this is what "printing to a file" actually means: you lose all semantic
information like letters, annotations, tags, etc.

While experimenting with this, I had also realized that text can no longer be selected after printing to a PDF file.
However when printing from Kate for example, the text is still selectable, so it seems to me like there might possibly be some way to maintain text when printing in Qt. (?)

Background: I wanted to evaluate the QPrinter based approach since it seems to have quite some advantages from an architectural point of view (platform-independent, not having to maintain printing-specific code at several places (Qt Okular,...)) and we plan to have some features implemented in the print dialog (for Qt/Okular).

However when printing from Kate for example, the text is still selectable, so it seems to me like there might possibly be some way to maintain text when > printing in Qt. (?)

That's interesting, but I don't currently have an idea how that is done. Somebody would need to delve into the kate code and have a look.

Without having looked at the code, here is a hypothesis of how Kate can print to a pdf file and have the text remain selectable. The Arthur font drawing code uses the QPainter::drawGlyphRun method to paint individual glyphs/letters. That method only receives a position and a QGlyphRun object (which in turn contains a QRawFont and char codes). In my limited understanding, this mechanism makes selectable text impossible, because the unicode information is gone.

However, QPainter also has various drawText methods, which are given unicode text, and which use the current QFont set with the setFont method. Possibly, these methods make QPainter retain the letter information when painting onto a QPrinter representing a pdf file. However, QFonts cannot represent fonts that are embedded in a pdf document---you need a QRawFont for that. For kate this does not matter, for poppler it does.

Background: [...] and we plan to have some features implemented in the print dialog (for Qt/Okular).

Can I learn more about this somewhere?

rkflx added a comment.Oct 14 2017, 6:26 AM

Implement all of Henrik's suggestions.

Had a final look, looks mostly good to me now – thanks. See below for some minor nits. (Could not mark my old inline comments as done, I guess the original author has to do that…).

I implemented a longer "What's this" help, but I couldn't make it appear in the GUI. What's the magic button for that?

Normally you can right-click or use the question mark tool in the dialog's title bar. However, this does not seem to work with combobox popups (some focus issue, it does work with normal menu popups, though). The easiest solution for this would be to move all of the text to the tooltip, with \n for line breaks. If you want to get fancy, you could switch to radio buttons or add a text area next to the combobox with the explanation (but not sure if worth it).


page 21: parts of vector (?) illustration missing

A patch for this can be found at https://bugs.freedesktop.org/show_bug.cgi?id=103118

Amazing :) (but does not apply to Poppler's git master?) Here's another one: shadows on page 39. Currently I don't have time to hunt for more rendering bugs, but is there any way you could do an automated comparison between Arthur and Splash using Albert's PDF collection?

On the other hand one could argue that this is what "printing to a file" actually means: you lose all semantic information like letters, annotations, tags, etc.

In general "printing" can be used for more, e.g. selecting a subset of pages, creating n-up PDFs or "flattening" filled out PDF forms to read-only PDFs. Preserving fonts is also something you get when printing via CUPS or (similar to QPrinter) via Cairo in Evince. It's a nice-to-have property, but obviously not relevant for this patch.

QFonts cannot represent fonts that are embedded in a pdf document---you need a QRawFont for that.

Might be worth trying to ask the Qt experts on that, also as a followup to fdo#102290

generators/poppler/generator_pdf.cpp
99

i18n needed here?

101

pdf → PDF
postscript → PostScript

108

definitely i18n missing

110

pdf → PDF

Background: [...] and we plan to have some features implemented in the print dialog (for Qt/Okular).

Can I learn more about this somewhere?

Sorry for the late reply. We are working on a client release based on (K)Ubuntu 18.04. With our current client being based on (K)Ubuntu 14.04, this also includes the transition from KDE 4 to KDE 5 and Qt 4 to Qt 5, respectively.
While we currently have some custom patches for Qt 4 and the old Okular version, the plan is to get as many of the features as possible implemented upstream, if reasonably possible, in particular:

  • printer-specific options in the Qt 5 print dialog (s.a. https://bugreports.qt.io/browse/QTBUG-54464)
  • options for scaling and poster-printing (e.g. printing an A4 document on 4 A4 pages that together form an A2 poster), in particular for Okular

A contractor is involved for the evaluation and implementation part.
I'll send you a few more pieces of information by personal email.

cfeck added a subscriber: cfeck.Dec 20 2017, 5:19 PM

What's the status of this patch?

sander added a comment.Mar 2 2018, 9:20 PM

Albert's main objection against this patch was that the Arthur backend is too bad to make the QPrinter approach worthwhile. Arthur has improved a bit since this patch was originally posted. It is still far from being perfect, but whether it is 'too bad' now depends a bit on the types of documents you typically use. I've been wanting to implement a few more things (type3 font support, in particular) this spring break, but unfortunately I currently find myself too busy with other things.

sander updated this revision to Diff 37025.Jul 2 2018, 5:25 AM

Implemented all suggestions concerning i18n and capitalization.

sander marked 12 inline comments as done.Jul 2 2018, 5:26 AM
sander added a comment.Jul 2 2018, 5:39 AM

I just uploaded a new version of the diff that fixes all remaining issues. Also, I implemented type 3 support in the Arthur backend, and it is already in poppler 0.64. That was the last blocker that prevented me from being able to use the Arthur backend in my daily work.

At this point, I am unlikely to fix further Arthur bugs just for the fun of it. This raises the questions about the future of this diff. I see basically three options:

  • If there is agreement that QPrinter printing is desirable then the patch should be pushed, possibly after further improvements.
  • If there is no such agreement we may as well close this diff now. Arthur will not improve further unless there is a real need.
  • As a compromise, I could modify the diff to be 'windows only'. I would need a bit of help with testing, though.

Opinions?

rkflx added a comment.Jul 7 2018, 11:09 AM

Thanks for the update. Still found some minor things, otherwise LGTM.


Unlike for CUPS printing, Qt printing prints on the entire page and does not scale to the printable area yet. This is only because it is the easiest way. I plan to implement a few standard scaling methods in a subsequent patch, which will only be a few additional lines of code.

Has this been worked on? If not, there should be a hint in the tooltip.

being able to use the Arthur backend in my daily work.

I guess you don't print annotations then ;) For me, highlighter annotations are rendered opaque. Not a blocker, of course, but maybe worth to file a bug for.

In D7949#155133, @rkflx wrote:

I implemented a longer "What's this" help, but I couldn't make it appear in the GUI. What's the magic button for that?

Normally you can right-click or use the question mark tool in the dialog's title bar. However, this does not seem to work with combobox popups (some focus issue, it does work with normal menu popups, though). The easiest solution for this would be to move all of the text to the tooltip, with \n for line breaks. If you want to get fancy, you could switch to radio buttons or add a text area next to the combobox with the explanation (but not sure if worth it).

There is still no way to get to the longer explanations. I'd suggest:

  • For the CUPS entry: Use what you currently have for WhatsThisRole for the text of ToolTipRole.
  • For the QPrinter entry: Only set the text of ToolTipRole, which should be fine as-is. Possibly move the rest of the text to a comment in the code.

At this point, I am unlikely to fix further Arthur bugs just for the fun of it. This raises the questions about the future of this diff. I see basically three options:

  • If there is agreement that QPrinter printing is desirable then the patch should be pushed, possibly after further improvements.
  • If there is no such agreement we may as well close this diff now. Arthur will not improve further unless there is a real need.
  • As a compromise, I could modify the diff to be 'windows only'. I would need a bit of help with testing, though.

    Opinions?

IMO the current state is good enough to ship it as a non-default option. As it is quite hidden behind buttons and tabs, I guess it's quite unlikely that there will be many bug reports about problems created through accidental activation of the option.

@aacid @michaelweghorn Any further comments?

generators/poppler/generator_pdf.cpp
105

Remove extra space before "This", add linebreak with <nl/> (needs xi18n instead of i18n).

PDf → PDF

118

Add colon.

1323

Coding style: Add spaces around ==.

sander updated this revision to Diff 37521.Jul 10 2018, 6:49 PM

Applied Henrik's suggestions

Restricted Application added a subscriber: okular-devel. · View Herald TranscriptJul 10 2018, 6:49 PM
sander updated this revision to Diff 37522.Jul 10 2018, 6:52 PM
sander marked 3 inline comments as done.Jul 10 2018, 7:02 PM

>Unlike for CUPS printing, Qt printing prints on the entire page and does not scale to the printable area yet. This is only because it is the easiest way. I > >plan to implement a few standard scaling methods in a subsequent patch, which will only be a few additional lines of code.

Has this been worked on? If not, there should be a hint in the tooltip.

That is https://phabricator.kde.org/D7962 . I put it on hold, because I didn't want to spend more time on time before knowing whether this patch here will get merged or not.

> being able to use the Arthur backend in my daily work.
I guess you don't print annotations then ;) For me, highlighter annotations are rendered opaque. Not a blocker, of course, but maybe worth to file a bug for.

That is interesting. Arthur renders them correctly to a screen, but I can confirm that they are opaque when printed.
Could this be a QPrinter bug? It is the same poppler backend code for screen and printer output.

That being said, highlighter annotations were a bit difficult to implement in Arthur, because they use a pdf
feature called 'transparency groups', which maps badly to Qt.

I also implemented all your further suggestions. I hope I understood them correctly: not sure where you wanted the colon to be.

rkflx accepted this revision.Jul 10 2018, 8:38 PM

Thanks, accepting the Diff from my side (obviously I cannot speak for the Okular project).

That is https://phabricator.kde.org/D7962 . I put it on hold, because I didn't want to spend more time on time before knowing whether this patch here will get merged or not.

Ah, I knew there was a Diff somewhere. Also, there is now D10974: Add option to ignore print margins for non-PDF generators, so this probably needs some coordination. Anyway, I don't think it's mandatory to wait for that, you could just add a hint to the tooltip that QPrinter does not scale to the printable area yet.

BTW, if you write D7962 instead of https://phabricator.kde.org/D7962, Phabricator will automatically add mentions to the review, which makes discovering things easier. Also, dependencies can be expressed with a line in the summary, e.g. Depends on D7949 (here you could use Edit Related RevisionsEdit Child Revisions).


For me, highlighter annotations are rendered opaque. Not a blocker, of course, but maybe worth to file a bug for.

That is interesting. Arthur renders them correctly to a screen, but I can confirm that they are opaque when printed.
Could this be a QPrinter bug? It is the same poppler backend code for screen and printer output.

You are the expert here, so I guess it's up to you to fix or at least report this at the appropriate place ;)

generators/poppler/generator_pdf.cpp
105

As there is no way to access Qt::WhatsThisRole from the UI, perhaps the line for Qt::ToolTipRole is enough?

This revision is now accepted and ready to land.Jul 10 2018, 8:38 PM

In general, I really like the idea of providing this new option.

Two notes after having a quick look (besides the two comments directly on the code):

  • Depending on what the use case for the option is (Will users who want to use this experimental feature have it enabled "all of the time" or is it actually an option that is meant to be changed per print job?), it might possibly be an alternative to move it to the config options of the PDF backend (which are available at "Options" -> "Configure backends" -> "PDF"), which would even further "hide" it from users who don't know about it. (Just to mention it, I don't have a strong opinion on this at the moment.)
  • As far as I can see, this also changes how the "Force rasterization" behaves for the CUPS case, since it now actually no longer uses QPrinter for this case now. This is possibly intended. (Just to mention that this will change the current behaviour. here also when the new experimental option is not selected.)

(I did not find the time to actually test or look at the change more intensely yet.)

generators/poppler/generator_pdf.cpp
99

Should "this" be passed in the constructor to have this auto-destroyed and avoid a memory leak?

1349

The indentation here is a little odd in my eyes, since the "if" is indented further than the following lines inside of the "if" block. I think moving the "if" (and "else" below) one indentation level to the "left" and the block one indentation level to the "right" would be the usual way to do it.

The patch should not influence the behavior of rasterized printing. The code used QPrinter with the poppler splash backend before, and it should still do that.

Thanks for all the heads up given in this thread, but since Albert was so much opposed to this patch at least originally, I will not push it without explicit consent from him.

generators/poppler/generator_pdf.cpp
1349

The idea was the following: New conditional are introduced that surround existing code. For nice identation all of that would have to be reformated, which makes for a patch full of whitespace changes. I didn't want that, but the new code has been indented directly at the correct indentation. At least that was the plan...

The patch should not influence the behavior of rasterized printing. The code used QPrinter with the poppler splash backend before, and it should still do that.

I might be wrong, but my observations seem to indicate the behavious has changed.
As far as I understand, the PSConverter/FilePrinter code path is now used for the forceRasterize option as well (rasterization being enabled by the call to psConverter->setForceRasterize(forceRasterize)).

One way to validate this (besides debugging) is also to check what kind of print file is passed to CUPS, i.e. located in /var/spool/cups/ for the respective print job.
Previously, CUPS was passed a PDF print file (generated by the QPrinter approach), while a PostScript file is now passed (generated by the Poppler::PSConverter and then passed via FilePrinter).

Thanks for all the heads up given in this thread, but since Albert was so much opposed to this patch at least originally, I will not push it without explicit consent from him.

My impression was that the main concern is/was that the Arthur backend is/was not yet ready "to be exposed to the ordinary user", since it may cause all kinds of problems (@aacid: Please correct me if I'm wrong.).
As I mentioned in my previous comment D7949#290186, I think it MIGHT help to better "hide" the option in the options of the PDF generator, since I guess "ordinary" users will probably not play with those so much and thus become "irritated" (but what do I know?).

Also, would it make sense to have an (additional?) experimental option to enable the Arthur backend in general, i.e. for showing the content on screen (as a separate change), so people who really want to experiment can do so even more?

michaelweghorn added inline comments.Jul 20 2018, 2:19 PM
generators/poppler/generator_pdf.cpp
1349

I don't know what "the right way" to handle this is within the Okular project. I just personally found the code a bit hard to read like this.

Also, would it make sense to have an (additional?) experimental option to enable the Arthur backend in general, i.e. for showing the content on screen (as a separate change), so people who really want to experiment can do so even more?

That is https://git.reviewboard.kde.org/r/130235/ , also quite contentious. :-)

About the rest: I admit that I didn't check thoroughly. I'll be offline for the next two weeks, and get back to it afterwards.

rkflx resigned from this revision.Aug 24 2018, 10:48 PM
This revision now requires review to proceed.Aug 24 2018, 10:48 PM

Where are we at with this? What are the blockers to landing it?

sander updated this revision to Diff 48405.Dec 30 2018, 4:02 PM

Rebased to current master, and connected the code to the new print scaling modes.

Where are we at with this? What are the blockers to landing it?

Partly: I am still unsure how much interest there actually is for this patch. If you like it and you would like to see it in Okular, please speak up.

I'm still interested! Anything that improves Okular's printing reliability is a good idea in my book. :)

I'm still interested! Anything that improves Okular's printing reliability is a good idea in my book. :)

+1 if it counts.

aacid added a comment.Dec 31 2018, 8:53 AM

I'm still interested! Anything that improves Okular's printing reliability is a good idea in my book. :)

Don't want to bash anyone but printing with the poppler Arthur backend is for sure not going to "improve printing reliability" given how low it's general quality is.

I find the approach interesting at least. However, I currently don't know enough of the different Poppler backends to really assess the situation properly. My thought was that it might possibly make sense to add an experimental option to enable this and https://git.reviewboard.kde.org/r/130235/ if the Arthur backend has general advantages over Splash and there was the plan to get it "production-ready". Can anybody quickly explain what the situation and plan with those backends is or is that too complex?

The quality of the Arthur backend really depends on what you use it for. For example, I personally mostly use Okular for scientific articles and presentations, and Arthur works almost perfectly for that. But for other types of documents, however, the situation may be different. Only Albert and his test suite know. :-)

I wouldn't mind fixing more bugs in Arthur if people request that. It's not even very difficult, but of course it is debatable whether maintaining three backends makes sense. I found the Cairo-to-Qt-backend quite interesting, but I haven't heard from that for a while. What I am afraid of, though, is that it seems like the Qt paint interface is not rich enough for the needs of a poppler backend. For example, there does not seem to be a way to draw a glyph by index and tell Qt what the corresponding letter is. As a consequence, text search in a pdf file printed by QPrinter cannot work. Probably only a dedicated effort by one of the bigger players (like you guys, Michael), can change that.

Thanks for the explanation!

I found the Cairo-to-Qt-backend quite interesting, but I haven't heard from that for a while.

There's a GitHub project at https://github.com/giddie/poppler-cairo-backend , but from how I read the related bug report, upstream integration is very unlikely.

[...] Probably only a dedicated effort by one of the bigger players (like you guys, Michael), can change that.

Frankly speaking, unfortunately new "circumstances" make a greater involvement from our side in such a project with limited short-term advantage rather unlikely (speaking just from the "bigger players" perspective, not necessarily my own personal one...).

There's a GitHub project at https://github.com/giddie/poppler-cairo-backend , but from how I read the related bug report, upstream integration is very unlikely.

What I meant was rather https://stackoverflow.com/questions/1639895/cairo-and-qt-integration .

aacid requested changes to this revision.Feb 21 2020, 6:55 PM

Please move as a Merge Request in https://invent.kde.org/kde/okular

We have pre-commit CI and lots of checks including clazy and clang-tidy there so it's a much better place for doing the review/approval/merge of the code.

This revision now requires changes to proceed.Feb 21 2020, 6:55 PM