GNOME Bugzilla – Bug 794703
Corrupted PDF causes UI drawing artifacts
Last modified: 2018-05-22 17:34:19 UTC
Looking at https://bugzilla.redhat.com/show_bug.cgi?id=1557355, I've found that the PDF there has way to large values in its transformation matrix which causes CAIRO_STATUS_NO_MEMORY error. This is not handled in evince. I think that status of the cairo context should be checked in evince because it creates the context. Not handling this causes drawing of black boxes in place of randomly chosen widgets used for drawing of evince UI.
Created attachment 370155 [details] [review] Don't show corrupted cairo surfaces
Review of attachment 370155 [details] [review]: Hi Marek, while I agree this is a step forwards, just killing the surface actually makes evince to think the page has not loaded yet.... so you get the loading... thingie when you are in a page that can't be rendered. I wonder if we can do something about it without disturbing the API too much... DO you have any thoughts about that?
Hi José, if it would be just about the "Loading..." message then we can check the status of the surface in draw_one_page() and not show the message if there is an error. Otherwise we could show that there is a problem with drawing of the page via a special page (with a sad face or something - this would need a cooperation with a designer) or use EvMessageArea for showing a message about wrong rendering.
EvMessageArea sounds more straightforward. Alhough, I wonder about the user interaction. Is it going to nag the users any time it tries to render the broken page? or just the first time. FWIW, I also added a link to the bug in poppler.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/evince/issues/887.