I see. So there is simply no option to disable the tooltips? And what does OSD mean anyway?

Thanks for the patch.

Fine with me. If you want I can post a separate QHash -> QMap cleanup patch. Either way, for me this patch can land in git.

Looking good! Concerning the preparatory commit 9ba8dd2cd7838c626af79a4edcd8b8437205cc02 , which copies the list of loaded generators from a QHash to a QMap: Why not use a QMap for them right away? Certainly the number of generators is low enough such that the efficiency differences between a QHash and a QMap become negligible?

I tested https://phabricator.kde.org/D14820 and it works nicely. Thanks for your effort! I also like the fact that the entries get sorted now.

That's more than enough as an explanation, and too much to put it in the text. Can we simply mention the bug and diff numbers in the code?

I think some extra comment lines explaining why this code is necessary would be helpful here.

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?

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.

Implemented all suggestions. In particular, the new controls disappear now unless the experimental QPrinter option or 'force rasterization' is set. The code for this is not particularly elegant, and I'd be interested to hear from the Qt pros about how it should really be done.

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

Applied Henrik's suggestions

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.

Implemented all suggestions concerning i18n and capitalization.

I tried, but I still cannot reproduce it. I do see the spurious lines very very briefly when scrolling the hightlighted area into the viewport, but they are always removed.

@simgunz , I can't. Remember that I could never reproduce the artifacts that Albert is seeing. Therefore I cannot test whether your idea fixes them.

People in my field still use Movie annotations, by means of LaTeX/multimedia. Any improvement to their support is always welcome. :-)

I've tried to create a test document with Adobe Acrobat Pro DC but ended up
frustrated and unable to create Movie or Rendition Actions (except for the Page Open Action).

Thanks for the patch! I tested it, and it seems to do what it claims to do!

I tried the patch and it does what it claims to do. I have no further objections.

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.

I tried the patch, and it did not fix 386111 for me. But I use fractional scaling, so maybe that's to be expected.

Thanks for the patch. It seems to solve the problem for me.

Thanks for testing. However, I don't really know what do to now. Given that I am not very attached to this patch I might simply abandon it.

I still cannot reproduce Albert's problems locally, but after reading Christoph's link (thanks!) I found out that I can move the upper left corner of the border one pixel towards the lower right without uncovering the yellow rectangle. Please somebody test whether the new patch still produces these artifacts.

Move the top left corner of the dark border one pixel towards the lower right.

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

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

Implement all of Henrik's suggestions.

Hi guys, thanks for all the feedback. I'll look into it, but I'll be busy with other things during the next 10 days.

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.

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

Ah, now I see it. Yes, the patch seems to work: the sidebar header is now elided rather than simply cut off, and I can make the sidebar as large or as small as I desire.

I just tried the patch. On my German setting, the labels are usually also cut off to the left and to the right. Strangely, the patch doesn't really change that.

Indeed. I was somehow expecting this to happen automatically. :-)

This applies to all highlights, i.e. text selection too, are you sure we want that?

Such a @note seems like a good idea.

I may have take on at https://bugs.kde.org/show_bug.cgi?id=384143 myself. Any ideas on where to start looking?

To be honest, I liked your first patch better. Granted, that definition of reloadLock is elegant, but you need quite a bit of C++ experience to see its beauty. People without that will be scared.

From merely looking at the patches, I like this one better than Albert's. In Albert's patch, the fact that you have to set m_areWeReloading at every exit of the method slotDoFileDirty does feel like breakage waiting to happen.

The problem with drawing in presentation mode is now a bug tracker issue:

Another one is

Midair collision. I'm not saying it is not good to go. I am just saying that there are more HiDPI issues left.

I don't know. But as this thread's title is "HiDPI Support for Okular", and as Lukas has turned into an Okular rendering expert I just mention here everything I notice. Feel free to ignore me.

Hi Lukas, I tested and all my previous complaints seem to be resolved. Thank you!

I do see minor rendering artifacts every now and then. Single rows of pixels seem to occur twice---possibly on tile boundaries. See the attached example image: the center line of text is slightly stretched. This happens at certain zoom levels. I don't really know how to reproduce it reliably.

Incidentally, I found another Okular hidpi problem:

I just tested again, and it looks much better than before. Thanks!

I agree with Henrik again. Yes, the very wide thumbnails in Albert's screenshot are strange, but I don't see why we should actively prohibit them. Besides, even with a vanilla Okular I am able to make the thumbnails about twice as wide as the actual pages (screenshot on request). So Henrik's patch does not make things (much) worse in that regard.

Ah, I get it. But as rkflx I don't see the point of the size limit. The sideBar contains five known fixed-but-translated words. Either the size limit is too small for all possible translations. Then some of these translations look ugly. Or it is large enough, but then the size limit is pointless and could be removed.

Albert, I don't see how fixing the code would look like, either. Even if the max width would be given in some dpi-independent way, there would still be a size limit and translations of "Thumbnails" would be cut off. Are you proposing to use an dpi-independent size unit AND increasing the max size?

For me the patch didn't quite apply to the latest okular git master. Easy to fix, but still. The problem was the cosmetic changes in shell/main.cpp.