The highlighter tool does not work right, if you rotate the view of a document first. Instead of a highlighted text there appears a lens-shaped yellow object arbitrary on the page. But, if you rotate the pdf document to the normal orientation, everything works fine again. Reproducible: Always Steps to Reproduce: 1. Open a pdf document with okular 2. Rotate the page (e.g. view->orientation->rotate left) 3. Highlight some text (choose tool: F6->4) Actual Results: Instead of a highlighted text there appears a lens-shaped yellow object arbitrary on the page. Expected Results: Highlighted text Haven't tested it with different documents types (only PDF).
FWIW, this is still a problem as of KDE Applications 17.11.80 and Poppler 0.61. Note: - You get the lense-shaped object only for 90°/270° rotation and normal/horizontal text. - For 180° rotation the highlighting is simply rotated by 180° relative to the page. - For 90°/270° rotation the rotated grey text on the side in http://arxiv.org/pdf/1203.0690 is not lense-shaped, but rotated by 90°/270°.
*** Bug 403755 has been marked as a duplicate of this bug. ***
Created attachment 120266 [details] Where the highlighting goes if the view is rotated Explaining the issue with a screenshot. Seems like Okular passes the wrong RegularAreaRect to the highlighter tool, a RegularAreaRect that somehow got the page rotation applied. More explanation (for non-Okular-developers): * A RegularAreaRect is an object which describes an area on the page, consisting of N NormalizedRect objects. * A NormalizedRect is an object which describes a rectangular area on the page, using normalized coordinates. * Normalized coordinates go from 0 to 1, where 0 is one edge of the page, and 1 the opposite edge. By describing everything with normalized coordinates, everything can be painted on the correct place on the page, without knowing the actual page size (in pixels) from the beginning. RegularAreaRect, NormalizedRect, and the normalized coordinate system at all don’t store information about text orientation or page orientation. For page orientation, they (theoretically) simply assume 0°. Further reading: The class documentation is in core/area.h. I’m currently working on the documentation, see https://phabricator.kde.org/D21266
(In reply to David Hurka from comment #3) > Seems like Okular passes the wrong RegularAreaRect to the highlighter tool, > a RegularAreaRect that somehow got the page rotation applied. Experimented a bit on this. Still seems like the RegularAreaRect somehow gets transformed with the current page rotation, when TextSelectorEngine requests the selected page area from the page view. Actually, TextPage::textArea(TextSelection), which is creates the RegularAreaRect does a transformation on the RegularAreaRect, guessing the current page view rotation, and TextSelectorEngine doesn’t expect this. This gets visible when PagePainter is changed that it uses Quad::point(index) instead of Quad::transformedPoint(index). Then the annotation is always oriented the same, and correct if the page is rotated like when the annotation was created. Only works with non-PDF documents, otherwise PagePainter is not used. May be easy to fix, just remove the transformation call in TextPage::textArea(). ---bit off topic--- Annotation generation is a bit strange. There are some AnnotatorEngine subclasses, which handle mouse events etc. to create an Annotation object containing all the needed geometry. But PageViewAnnotator::performRouteMouseOrTabletEvents() passes them points from the rotated page (double nX, nY). Although comments in the source code say that (nX, nY) is a normalized point, it doesn’t simply pass a NormalizedPoint which is independent of page rotation. When the Annotation Object is complete, Document::addPageAnnotation() does a baseTransform on the Annotation, to correct for page view rotation. Considering the mentioned source code comment, this seems like a hack. And somehow, this does not affect highlight annotations - removing the baseTransform only breaks the other annotation tools. @Developers: Would it make sense to refactor AnnotatorEngine stuff a bit to work with true NormalizedPoints exclusively?
*** Bug 407865 has been marked as a duplicate of this bug. ***
Hi, the bug is still occurring in 1.11.3, not only for the highlighter but also the striker and co.