If DPI in X != DPI in Gnome, document dimensions are not true at 100% zoom

Bug #311614 reported by Stefano Maggiolo on 2008-12-26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
evince (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Binary package hint: evince

From File->property you can get the dimensions of a PDF you're viewing.
At 100% zoom level, the document is about 20% smaller (in each dimension) than it should be.
For comparison, screenruler shows the right dimensions, so it should be possible taking screenruler's detection algorithm which seems to work better.

The cause is a discrepancy between the DPI value in Gnome and in X: All other programs read the Gnome value, while Evince reads from X.

Dimitrios Symeonidis (azimout) wrote :

Stefano, does this happen to all pdf files in your machine?
Here's a similar screenshot from mine, where the dimensions seem right...

Changed in evince:
importance: Undecided → Low
status: New → Incomplete

Yes, every one displays in the same way. Now that I think of it, I remember I've played with DPI settings some time ago.

Indeed, xdpyinfo tells me 96x96 dots per inches; in gnome-appearance-properties I have 114 DPI. If I put 96 DPI in the gnome configuration, evince and screenruler agree on the dimensions, but they're both wrong.

So I think evince take the information from xdpyinfo and not from gnome (AFAIK 114 DPI is the right choice for my Macbook).

Btw, if you know how to change X configuration, can you tell me? Maybe I should have to change it anyway...

Dimitrios Symeonidis (azimout) wrote :

the way to change DPI in X is to run "xrandr --dpi <dpi>"

this seems a complicated case: as you see from my screenshot, evince is correct, but xdpyinfo gives me wrong screen dimensions (in millimeters)...

Okay. Now I've changed X DPI settings to 114; nothing changed in the Gnome desktop (I think because all nice Gnome libraries use the 114 DPI from Gnome configuration), nothing changed in screenruler (which already gave the right dimensions) and now also evince and xdpyinfo give true dimensions. I'm happy.

So it seems that at least in my case evince look to X DPI settings and not to Gnome's. Just to be sure, these are my versions (Intrepid defaults):
evince 2.24.1-0ubuntu1
libpoppler-glib3 0.8.7-1
libpoppler3 0.8.7-1


Dimitrios Symeonidis (azimout) wrote :

Marking as triaged. Should we forward this upstream, or is it a "won't fix"?

description: updated
Changed in evince:
status: Incomplete → Triaged
Changed in evince:
assignee: nobody → desktop-bugs
status: Triaged → Confirmed
Sebastien Bacher (seb128) wrote :

the bug should be sent to bugzilla.gnome.org by somebody considering the behaviour as buggy and wanting to argue with them about what it should be doing

Dimitrios Symeonidis (azimout) wrote :

the question is, should we request that evince reads DPI from Gnome instead of X, or should we ask for x.dpi == gnome.dpi ???

Kiri (kiri) wrote :

Dimitrios, I think the latter: "x.dpi=gnome.dpi' .
Or at least, the user should be able to configure GNOME to use the X Windows DPI at any time, without manually looking up what the X Windows DPI is and entering the same number into the GNOME configuration.
A GNOME DPI setting should really be for emergency use only, not normal use. The window system, whether X or MS, should normally be the authorative source.

Germán Poo-Caamaño (gpoo) wrote :

This might be a bug in screenruler. If I change the DPI of the screen and the document is set to 100% (representing physical size), then, the document should change its size. That is, if the document is A4 and I put an actual A4 sheet on top of the screen, changing the DPI should not change the document size.

Nevertheless, the 100% zoom of evince 3.8 is slightly wider in my screen in 3.8 (not smaller)

Changed in evince:
importance: Unknown → Medium
status: Unknown → New
Changed in evince:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.