Bug 388458

Summary:	Wrong size of rectangles around annotation icons (e.g. popup note) for PDF documents
Product:	[Applications] okular	Reporter:	Tobias Deiminger <haxtibal>
Component:	PDF backend	Assignee:	Okular developers <okular-devel>
Status:	ASSIGNED ---
Severity:	normal	CC:	nate, null, simonandric5
Priority:	NOR
Version:	1.3.0
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	A5 pdf in Okular window with QT_SCALE_FACTOR=3

Description Tobias Deiminger 2018-01-02 13:24:08 UTC

This is reproducible with almost any PDF document. If you left click on an annotation icon, or while moving the icon around with the mouse, rectangles are drawn around the icon. These rectangles are too big or too small in most cases. How, and how much they misfits depends on PDF page size and on screen DPI. Only in rare cases the rectangle fits exactly with the icon rendered by Poppler.

The problem is closely related to https://bugs.kde.org/show_bug.cgi?id=387639. I filed a second bug do describe the PDF specific part of the issue, while #387639 describes the hidpi specific part.

Here is a summary for why this happens:
-Okulars PickPointEngine creates linked TextAnnotations with a hardcoded width of 0.03 (a normalized value, where 1 means full page width) [1]
-Poppler ignores the size right away and forces it to hardcoded 24x24 pts == 0.33x0.33 inch [2]
-to draw the rectangle, Okular denormalizes the value 0.03 from above to page width in screen pixels [3], [4]
-therefore the rectangle size depends on current DPI and PDF page size in pts, while the icon rendered by poppler is independent from both

I'll share a patch on Phabricator soon which fixes the bug for me, and probably fixes #387639 too (can't test the latter due to lacking hidpi setup).

Yet another part of the issue is that Poppler silently ignores what applications set in Poppler::Annotation::setBoundary. This should IMHO get fixed at Poppler side, or at least should be clarified why forcing 24x24 pts was necessary. We can only work around it in Okular.

[1] https://cgit.kde.org/okular.git/tree/ui/pageviewannotator.cpp?h=Applications/17.12#n213
[2] https://cgit.freedesktop.org/poppler/poppler/tree/poppler/Annot.cc?h=poppler-0.62.0#n2469
[3] https://cgit.kde.org/okular.git/tree/ui/pagepainter.cpp?h=Applications/17.12#n805
[4] https://cgit.kde.org/okular.git/tree/ui/pageviewmouseannotation.cpp?h=Applications/17.12#n271

Comment 1 null 2018-01-02 20:07:19 UTC

Thanks for digging into this, looking forward to the Phabricator review.

> can't test the latter due to lacking hidpi setup
HiDPI testing should be easy with something like "QT_SCALE_FACTOR=2.4 okular".

Ref. https://doc.qt.io/qt-5/highdpi.html

Comment 2 Tobias Deiminger 2018-01-03 09:37:29 UTC

Created attachment 109645 [details]
A5 pdf in Okular window with QT_SCALE_FACTOR=3

This is how QT_SCALE_FACTOR=3 looks on my non-hidpi (1920x1080 at 21,6") screen. Diff 24634 from D9615 is applied and seems to work because rectangle matches around popup note icon. But widgets are huge, while PDF page looks the same as without setting QT_SCALE_FACTOR. Why is the PDF page at 100% zoom not three times bigger as well? Is this a valid test case?

Comment 3 null 2018-01-03 18:42:18 UTC

> widgets are huge, while PDF page looks the same
In general Okular should display documents based on the physical dimensions as specified in the PDF, e.g. for 100% zoom of an A5-sized document you should be able to get the same size measurements with a ruler as when measuring a real A5 paper on your desk.

IOW, this depends on the (hardware) DPI of the monitor, but not a user-set (virtual) DPI to scale UI elements.

Comment 4 Bug Janitor Service 2021-04-23 18:53:15 UTC

A possibly relevant merge request was started @ https://invent.kde.org/graphics/okular/-/merge_requests/412