After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 526972 - Postage stamp sized image
Postage stamp sized image
Status: RESOLVED DUPLICATE of bug 608586
Product: evince
Classification: Core
Component: PDF
2.22.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-04-08 16:14 UTC by Peter Bloomfield
Modified: 2013-02-06 12:26 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Proposed patch (499 bytes, patch)
2008-04-09 11:16 UTC, Peter Bloomfield
none Details | Review

Description Peter Bloomfield 2008-04-08 16:14:48 UTC
Since updating to 2.22.1 (evince-2.22.1-1.fc9.i386), I can't get evince to show a US-letter pdf file as an image larger than 82 x 114 pixels (and that's at 400%).  The problem exists with pdf files I've made with pdflatex, and other files from the web.

The previous version was 2.20.2 (evince-2.20.2-1.fc8.i386.rpm from F8 updates).
Comment 1 Peter Bloomfield 2008-04-08 16:22:06 UTC
OK, I downgraded and still have the problem--must be a system setting--sorry for the noise.
Comment 2 Peter Bloomfield 2008-04-09 11:16:35 UTC
Reopening: as noted on the list, evince uses gdk_screen_get_{width,height}_mm  
in calculating the display's dpi, and the Gnome docs note that "on some X  
servers this value will not be correct".  The possibly incorrect dpi is then used to set view->min_scale and view->max_scale.  The latter, view->max_scale, is used to cap view->scale for EV_SIZING_BEST_FIT and EV_SIZING_FIT_WIDTH.

Clamping view->scale for EV_SIZING_FREE seems reasonable, and may make zooming infeasible with a broken X server.  But EV_SIZING_BEST_FIT and EV_SIZING_FIT_WIDTH are requesting a scale based on pixel counts.  This scale is presumably more reliable than the dpi, and should be trusted even when apparently inconsistent with the dpi.

Patch to follow.
Comment 3 Peter Bloomfield 2008-04-09 11:16:51 UTC
Created attachment 108917 [details] [review]
Proposed patch
Comment 4 Nickolay V. Shmyrev 2008-04-11 05:26:38 UTC
Thanks for the patch and investigation.

Sorry, but I don't quite understand how clamping at min_scale could solve the problem. I agree that Evince must take care about incorrect result caused by drivers, but min_scale is still a very small value. Images will still have small size even with a patch applied.

While this patch breaks fit window for very small window sizes.
 
Comment 5 Peter Bloomfield 2008-04-11 11:32:10 UTC
I must have misunderstood the meanings of the EvSizingMode enum.  My intention was to remove clamping for "fit width" and "fit window".  As I understand it, currently the scale is clamped to (min_scale, max_scale) for zoom actions, and to (0, max_scale) for "fit width" and "fit window" (that is, merely capped at max_scale, since the scale is never negative).  I just meant to remove the cap.  Is this not the correct place to do that?
Comment 6 Peter Bloomfield 2008-04-11 14:59:25 UTC
I just tested the patch on the system with the X server problem: "fit width" and "fit window" both work, while zooming is still limited to 400% of a tiny size.

The server problem has, in the interim, been fixed <https://bugzilla.redhat.com/show_bug.cgi?id=441848>, so I also tried the patched Evince with a sane server, and now zoom works as expected.  "Fit width" and "fit window" continue to work, even with the window shrunk as far as the menu bar allows.
Comment 7 José Aliste 2013-02-06 12:26:59 UTC
Marking as duplicate as this depends on the failure of computing good dpi using gdk_screen apis and I propose that we replace this with gdk_screen_get_monitor apis.

*** This bug has been marked as a duplicate of bug 608586 ***