GNOME Bugzilla – Bug 685334
Evince does not read comments in PDF exported from LibreOffice
Last modified: 2015-06-05 12:05:18 UTC
Created attachment 225626 [details] test case When opening in Evince a PDF created with LibreOffice (export) that contains comments, these comments although they appear as annotations (displayed icon in grey color + in the annotation list) are not readable (clic on the icon has no effect). In addition, if a new annotation is added in Evince, the grey icons of the LibreOffice comments disappear.
This also is reproducible in master (after 3.6.0).
poppler-glib-demo get the text ("This is the first comment" and "This is the second coment"), so I think it is an issue in Evince. I guess it could be related with the state of the comment (Unknown).
The annotations also disappear upon zooming. I get similar results for pdf files generated with Latex and the pdfcomment package.
The problem with both the LibreOffice and Latex generated PDF files seems to be that they have a very small or zero volume /Rect field. The annotations in the attached test case are in fact there. There is a very small area where hovering the mouse shows the first comment. Additionally, the annotations do not contain a /Popup field, which means clicking them does nothing.
This bug is reported for LibreOffice : https://bugs.freedesktop.org/show_bug.cgi?id=60126
Confirmed as per downstream report: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/992767 1) lsb_release -rd Description: Ubuntu Vivid Vervet (development branch) Release: 15.04 2) apt-cache policy evince libcairo2 libpoppler[0-9] evince: Installed: 3.14.1-0ubuntu1 Candidate: 3.14.1-0ubuntu1 Version table: *** 3.14.1-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status libcairo2: Installed: 1.13.0~20140204-0ubuntu1 Candidate: 1.13.0~20140204-0ubuntu1 Version table: *** 1.13.0~20140204-0ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status libpoppler47: Installed: 0.28.1-1ubuntu1 Candidate: 0.28.1-1ubuntu1 Version table: *** 0.28.1-1ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages 100 /var/lib/dpkg/status 3) What is expected to happen via https://bugs.launchpad.net/ubuntu/+source/evince/+bug/992767/+attachment/3123431/+files/Evince%20%E2%80%93%20Simply%20a%20document%20viewer.pdf is that on the first page, top box where it notes: Thumbnail sidebar showing while scrolling through a document. is one may click the box and a comment box pops up, as it does in Adobe Reader. 3) What happens instead is it doesn't.
Created attachment 302930 [details] [review] ev-view + ev-document: Make annotations with very small rectangles clickable. Some tools create pdf annotations with a /Rect field, whose volume is very small or zero. Nevertheless, one expects tool-tips when hovering them, or popup windows to appear when clicking them. This patch virtually enlarges the rectangle of annotations, where it is just too small. The issue with missing /Popup fields is already fixed in master. Applying this patch on top of master, makes evince behave as expected for the attached test case, as well as for PDF documents created using LaTeX + pdfcomment package.
Created attachment 302931 [details] [review] ev-view + ev-document: Make annotations with very small rectangles clickable. Same patch, this time properly formatted.
Review of attachment 302931 [details] [review]: Thanks for working on this. I think it's Ok, but I think you could simplify it a little bit. See bellow ::: libview/ev-view.c @@ +1629,3 @@ } static void I don't see the reason for changing the name and signature of this function. I would just use directly ANNOT_RECT_WIDTH and ANNOT_RECT_HEIGHT on ev_view_get_area_from_mapping and save the two parameters in the function.
Created attachment 302958 [details] [review] ev-view + ev-document: Make annotations with very small rectangles clickable. Changed name of the new function to to ev_view_get_annot_area_from_mapping to better reflect its just to be used for annotations. Removed the two superfluous parameters. Now the functions ev_view_get_area_from_mapping and ev_view_get_annot_area_from_mapping have exactly the same set of parameters. In ev_view_get_annot_area_from_mapping ANNOT_RECT_WIDTH and ANNOT_RECT_HEIGHT are used directly. Note that the function ev_view_get_area_from_mapping is called from ev_view_form_field_get_region and get_link_area. So applying the modifications directly in that function would have nasty effects for form fields and links like cursors changing and tool tips being displayed even when the pointer is not above those elements.
Ok, I understand and sort of agree (without having to test this yet) with what you say above. Are tooltips and cursors working correctly with your patch? And, can we have Forms or links with small rects? AFAIK, I don't think it is undesirable to enlarge small rects from form fields or links if they are too small to be clicked, but probably it needs more thinking about forms... and even, it might be impossible to get small rects for forms so you wouldn't get the undesirable effects in practice. Anyway, that's the only thing I don't like about your patch now. It's just that ev-view.c is already so complex that I really prefer that we add more static api if strictly necessary, but it's up to Carlos to decide. Thanks for working on this.
(In reply to José Aliste from comment #11) > Ok, I understand and sort of agree (without having to test this yet) with > what you say above. Are tooltips and cursors working correctly with your > patch? Yes. The patch ONLY affects cursors and tooltips for annotations. Handling of cursor to be shown is done in ev_view_handle_cursor_over_xy, where ev_view_get_annotation_at_location is used, as well as ev_view_get_link_at_location and ev_view_get_form_field_at_location. So the code paths about links and form fields remain unchanged. Then there is the function ev_view_query_tooltip using ev_view_get_annotation_at_location and ev_view_get_link_at_location. To determine the area for the tool tip, functions get_annot_area and get_link_area are used respectively. Only the former is modified by the patch to return a potentially enlarged area. > And, can we have Forms or links with small rects? Yes, see above. > AFAIK, I don't > think it is undesirable to enlarge small rects from form fields or links if > they are too small to be clicked, but probably it needs more thinking about > forms... and even, it might be impossible to get small rects for forms so > you wouldn't get the undesirable effects in practice. I do not know about form fields and links wrt. what the pdf spec says about them. But there is no bug report about forms or links not clickable. So it seems this is not an issue. On the other hand, annotations seem to be a feature, where there exist diverging interpretations of the spec, as indicated by the history of this bug and the bug report filed against libreoffice, which was closed as "not a bug". To cut a long story short: I think behavior for links and form fields should not be changed. But that's only my opinion. > Anyway, that's the > only thing I don't like about your patch now. It's just that ev-view.c is > already so complex that I really prefer that we add more static api if > strictly necessary, but it's up to Carlos to decide. Thanks for working on > this.
Thank you for the thoughtful explanation. I think your argument is stronger, not modifiying forms and links make sense as you explain. If later we see we have bugs about small forms or links, then we could merge the functions. For me the patch looks good.
Thanks for the patch. I'm not sure this is the right approach, though. The problem is specific to PDF documents, and even more concretely to PDF Text annotations (you are using 24x24 as the minimum annot rect). So, I think we should change the annotation area when creating the annotations in the pdf backend, and only for text annotations. Poppler always forces text annots to be 24x24 to prevent this problem, and also the opposite (huge text icons). // Force 24x24 rectangle PDFRectangle fixedRect(rect->x1, rect->y2 - 24, rect->x1 + 24, rect->y2); That's what it does for drawing the annot in the page. We can do the same when computing the annot area in the pdf backend, and the area will be exactly the icon area. This way we don't need any change in evince view. What do you think?
Created attachment 304582 [details] [review] pdf: Force text annotations to have a fixed size 24x24 Yes Carlos. You are right. This is much simpler than "fixing" the area in the view afterwards. Attached you find a patch that implements your suggestion.
Comment on attachment 304582 [details] [review] pdf: Force text annotations to have a fixed size 24x24 Perfect, pushed to both branches. Thanks!