After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768246 - Annotations appear at the wrong place
Annotations appear at the wrong place
Status: RESOLVED NOTGNOME
Product: evince
Classification: Core
Component: pdf annotations
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 744220 749342 767491 772498 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-06-30 14:15 UTC by ralf.evince
Modified: 2017-11-05 18:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot (253.35 KB, image/png)
2016-06-30 14:15 UTC, ralf.evince
Details

Description ralf.evince 2016-06-30 14:15:14 UTC
Created attachment 330659 [details]
screenshot

When doing annotations on old an old pdf the annotation (yellow highlight) shows up at the wrong position. See the attached screenshot, where I have tried to annotate the headline of the text ("Time series properties of an artificial
stock market") - but this happens for every part of text in the pdf (which I have tried). However I get the annotation window when i click on the text which I annotated and not when I click on the yellow area.
Since the pdf on which I have noticed this bug is copyrighted I will not upload it here (you can download it here: http://www.sciencedirect.com/science/article/pii/S0165188998000815 or send me an Email if you do not have access to it).
The pdf is PDF-1.2 and was created using "Acrobat Distiller 3.02 for Power Macintosh" in the year 1999.

This is not the first old pdf in which I have noticed this behaviour, however newer pdf's usually work as expected.
Comment 1 Germán Poo-Caamaño 2016-06-30 15:15:30 UTC
Thank you for reporting the issue.

This issue is in poppler, the library used by Evince to render PDF documents, as it is reproducible with poppler-glib-demo.

Please, file a bug in https://bugs.freedesktop.org/enter_bug.cgi?product=poppler
and add a link here to such bug.
Comment 2 Germán Poo-Caamaño 2016-06-30 17:44:31 UTC
For what it is worth, ezPDF does not show the problem. I mention it because ezPDF uses code (proprietary license) from xpdf. So, it is solvable.
Comment 3 ralf.evince 2016-07-01 16:21:52 UTC
Okay, I have filed the bug here: https://bugs.freedesktop.org/show_bug.cgi?id=96764
Comment 4 ralf.evince 2016-07-06 08:58:33 UTC
this might be still a bug in evince, since this problem does not occur with okular (see bugreport for the poppler library for the first page of the pdf to try it yourself)
Comment 5 Germán Poo-Caamaño 2016-07-06 17:12:38 UTC
(In reply to ralf.evince from comment #4)
> this might be still a bug in evince, since this problem does not occur with
> okular (see bugreport for the poppler library for the first page of the pdf
> to try it yourself)

Nope.  As I said in comment #1 the issue is reproducible with
poppler-glib-demo.

The problem maybe specific to the glib frontend of poppler, but that still
is poppler.

I just tried it again with poppler master, and the issue is there wit
poppler-glib-demo.

okular uses a different frontend (qt) of poppler, and there may be differences.
Comment 6 Germán Poo-Caamaño 2016-07-06 18:19:26 UTC
Indeed.

After uncompressing the PDF you posted in Poppler:

$ pdftk bug.pdf output bug-u.pdf uncompress

You can find that /MediaBox is different than /TrimBox and /Cropbox.

<<
/pdftk_PageNum 1
/Rotate 0
/TrimBox [38 40 422 659]
/Resources 4 0 R
/Contents 24 0 R
/Parent 41 0 R
/Type /Page
/Thumb 1 0 R
/MediaBox [0 0 468 681]
/CropBox [0 40 422 659]
>>

Just to test, I set all of them to [0 0 468 681] and poppler-glib-demo shows the highlight text where it is expected.

poppler-qt5 frontend (the one used by Okular) has a method to normalize the user coordinates with respect to the document. I believe that is what makes the difference.

See https://cgit.freedesktop.org/poppler/poppler/tree/qt5/src/poppler-annotation.cc#n202

poppler-glib does not have such normalization. I wonder why it should be normalized in the front-end and not in the core of poppler (or have an API for that).

Nevertheless, the way to solve it is having a helper either in poppler, to be consumed by the frontends or add a function in poppler-glib to normalized the coordinates.

Definitively not a bug in Evince. I am closing this bug, as once it is fixed in Poppler, Evince will behave properly.
Comment 7 Germán Poo-Caamaño 2016-07-19 07:05:27 UTC
*** Bug 749342 has been marked as a duplicate of this bug. ***
Comment 8 Germán Poo-Caamaño 2017-09-26 19:51:27 UTC
*** Bug 767491 has been marked as a duplicate of this bug. ***
Comment 9 Germán Poo-Caamaño 2017-10-02 13:56:25 UTC
*** Bug 744220 has been marked as a duplicate of this bug. ***
Comment 10 Germán Poo-Caamaño 2017-11-05 18:29:15 UTC
*** Bug 772498 has been marked as a duplicate of this bug. ***