| Summary: | Annotations appear at the wrong place | ||
|---|---|---|---|
| Product: | poppler | Reporter: | ralf.evince |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=768246 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
screenshot
the pdf file |
||
|
Description
ralf.evince
2016-07-01 16:21:05 UTC
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.