GNOME Bugzilla – Bug 719400
evince 3.10.3: 0% default zoom level on wayland/weston
Last modified: 2017-09-14 07:36:12 UTC
When opening a PDF document in evince in the wayland/weston environment, the zoom level textbox displays a value of 0%, while the actual document display appears normal (fit width). Furthermore, when using the 'CTRL-+' hotkey to increase the zoom level, a change from '0%' to '-nan%' is seen and a related libcairo error message* is spewed out. Manually typing a valid zoom level and then using the 'CTRL--' / 'CTRL-+' hotkeys works as intended though. setup: Arch Linux x86_64/evince-3.10.3-1/gtk 3.10.5-1 wayland-1.3.0-1/weston-1.3.1-1 * "Internal Error: cairo context error: invalid value (typically too big) for the size of the input (surface, pattern, etc.)<0a>"
After taking a quick look at the code in evince, I think the problem is arising from the way evince determines the screen DPI which it then uses to calculate the zoom level to accurately represent the document "true-to-life". From the bug below, it seems this is currently unimplemented in the gtk+ gdk wayland backend: https://bugzilla.gnome.org/show_bug.cgi?id=700737 I'm going to try "fixing" it by having evince fall back to 96dpi if it can't calculate the true value rather than having %NAN propagate all the way up to the UI.
Confirmed "fix". gdk_screen_get_mm() isn't returning anything on wayland, so the "return dp / di;" in ev_document_get_screen_dpi() results in division-by-zero, which then breaks all the subsequent assumptions about it being valid value. The complete fix is to obviously make it return the proper value with the wayland GDK backend in gtk+, but evince shouldn't just assume it works.
Created attachment 291737 [details] [review] Return 96 dpi if unable to determine true value
Comment on attachment 291737 [details] [review] Return 96 dpi if unable to determine true value Thanks for the patch. gdk_screen_get_width_mm and gdk_screen_get_height_mm are implemented in gdkscreen-wayland.c, so please, file a bug report to GTK+ too. But I agree we should prevent a division by zero in case those values are wrong for whatever reason. >--- libdocument/ev-document-misc.c.orig 2014-11-28 15:43:40.531413445 +0000 >+++ libdocument/ev-document-misc.c 2014-11-28 15:46:24.915173966 +0000 >@@ -517,7 +517,13 @@ > /*diagonal in inches*/ > di = hypot (gdk_screen_get_width_mm(screen), gdk_screen_get_height_mm (screen)) / 25.4; if dp is <= 0 at this point we can avoid the di calculation. Add an early return right after the dp calculation if it's invalid. And another one if di is invalid. >- return (dp / di); >+ /* If dp or di fails to return a valid value then return default 96 DPI, > * Otherwise (dp / di) can result in infinity, NaN or zero DPI > */ >+ if ((dp <= 0) || (di <= 0)) >+ return (96.0); >+ else >+ return (dp / di); > } Too many parentheses there. > /* Returns a locale specific date and time representation */
Created attachment 359479 [details] [review] libdocument: return 96 DPI if unable to determine true value
Comment on attachment 359479 [details] [review] libdocument: return 96 DPI if unable to determine true value Ok, thank you.
Attachment 359479 [details] pushed as fafa260 - libdocument: return 96 DPI if unable to determine true value