Created attachment 124843 [details] screenshot When doing annotations (using evince) on 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. This does not happen in foxitreader and apparently also not in ezPDF(https://bugzilla.gnome.org/show_bug.cgi?id=768246).
Without a file there's no hope for this to be fixed, i'd suggest you to use pdfseparate to separate the first page and attach it here, or find a pdf you can distribute that has the same problem.
Created attachment 124904 [details] the pdf file
Works fine with okular, can't say if it's a bug in evince or a bug in a poppler codepath that okular uses diferently.
according to the developer at the evince bug-tracker this is a poppler bug - see his arguments in https://bugzilla.gnome.org/show_bug.cgi?id=768246
It would be great to see this fixed! The arguments on the evince bug tracker concerning why this is a poppler bug seem rather cogent, plus they even point in the direction of a solution.
This is what German found out. 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.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/129.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.