GNOME Bugzilla – Bug 318285
100% view should match real size and take dpy into account
Last modified: 2006-12-14 11:46:50 UTC
Evince should take the monitor DPI into account when zooming pages to a percentage. 100% zoom in evince leaves documents (e.g. http://www.adobe.com/products/acrobat/pdfs/pdfaccess.pdf ) looking a different size to themselves at 100% in Acrobat 7. After some poking about I noticed that this was because evince does not take the reported monitor DPI into account when sizing documents against a percentage (xpyinfo reports 90x96 dots per inch ). Forcing the DPI to 72 in Acrobat makes the documents look the same.
True. We need corresponding poppler support, but evince should actually pass a value (72 or 96) to poppler.
*** Bug 343207 has been marked as a duplicate of this bug. ***
Hi, I filed bug 343207 on the Ubuntu launchpad. I want to mention that I have correctly set my DPI, I've measured my screen, and it turns out to have 98dpi.
Most programs are dependent on X telling them the DPI because it is rare that the user will put a ruler to the screen. Pascal: If xdpyinfo is giving you a DPI (significantly) different to what it should be this either an X/X driver/Bad monitor DDC issue and thus seperate from this bug.
Well xdpyinfo does return proper DPI information: dimensions: 1680x1050 pixels (431x272 millimeters) resolution: 99x98 dots per inch
*** Bug 351397 has been marked as a duplicate of this bug. ***
Please note, that other backends like dvi and djvu should render at correct size as well
I'm not sure it's a good idea to change DPI -> dpy in the subject of this bug as I think it will make it harder to find. I'm not even sure what dpy stands for...
*** Bug 375165 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > True. We need corresponding poppler support, but evince should actually pass a > value (72 or 96) to poppler. Glancing at the code, it seems that poppler returns page metrics etc. in point (ie 1/72th of an inch). However, these metrics seem to be taken as-is as pixel values, leading to an effective resolution of 72 dpi. So what needs to be done is probably to fix the point->pixel conversions to take the display resolution into account (ie 'metric_in_pixel = metric_in_pt * (screen_res / 72.0);').
Created attachment 77812 [details] [review] Patch Here is a patch that I think fixes the problem. It adjusts the scale in ev-window according to screen dpi. We assume now that all the backends render at 72.0 dpi. Please, review it to make sure it really fixes the bug.
Ok, I've just committed a slightly modified version of the patch.