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 646414 - No display of B/W TIFF images with resolution 0x0dpi
No display of B/W TIFF images with resolution 0x0dpi
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
2.30.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 676295 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-01 07:25 UTC by Florian W.
Modified: 2014-10-20 08:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Sample TIFF (4.02 KB, image/tiff)
2011-04-01 07:25 UTC, Florian W.
  Details
First try to use sane defaults (1.08 KB, patch)
2014-10-10 09:57 UTC, Gabor Kelemen
committed Details | Review

Description Florian W. 2011-04-01 07:25:41 UTC
Created attachment 184854 [details]
Sample TIFF

(B/W) TIF-images set to 0x0dpi resolution are not displayed.

Error Message: Document contains only empty pages

This bug is present in Windows XP and Ubuntu 10.10/10.04
Comment 1 Gabor Kelemen 2014-10-10 09:50:39 UTC
*** Bug 676295 has been marked as a duplicate of this bug. ***
Comment 2 Gabor Kelemen 2014-10-10 09:53:51 UTC
I had to look into this.

The error string comes from ev-window.c, where it uses ev_document_check_dimensions() to check if any dimension of the image is 0. 
The document's dimensions for TIFF files are set in tiff-document.c, where tiff_document_get_page_size() queries the image width and lenght, then uses the resolution returned by tiff_document_get_resolution() to scale the image - that is, it multiplies the lenght with the x_res/y_res ratio. The latter can be zero, and thus one of the image dimensions too. 
The problem is in tiff_document_get_resolution(), because it first gives default values to the x and y variables, then overwrites them with the values the TIFF image contains. 
Some TIFF generating software set resolution incorrectly to `0 , 0` (Irfanview in particular - the document in this bug, then the one in the duplicate #676295 and the "first Google hit for `multipage tiff sample image`" document at http://www.nightprogrammer.org/wp-uploads/2013/02/multipage_tif_example.tif were all generated with it).

So I think the solution could be to query the TIFF for its resolution, then check if the value is nonsense like 0, and in this case use some sane defaults.
Comment 3 Gabor Kelemen 2014-10-10 09:57:44 UTC
Created attachment 288196 [details] [review]
First try to use sane defaults

First try to solve the problem. I'm not sure what happens if the TIFF is indeed garbage, i.e. the 0 resolution is correct, so more checks on that may be necessary. But the sample documents are displayed correctly this way, so at least a start :).
Comment 4 Carlos Garcia Campos 2014-10-19 13:41:39 UTC
Review of attachment 288196 [details] [review]:

Thanks for the patch, I've just pushed it with the suggestion I mention below.

::: backend/tiff/tiff-document.c
@@ +193,3 @@
+	if ( (int) y == 0 ) {
+		y= 72.0;
+	}

Why do you need the casts?

@@ +197,2 @@
 	*x_res = x;
 	*y_res = y;

I would simplify this doing something like:

*x_res = x > 0 ? x : 72.0;
*y_res = y > 0 ? y : 72.0;
Comment 5 Gabor Kelemen 2014-10-20 08:04:24 UTC
Hi Carlos

Thank for the review and commit. I'm not that good at coding, so thanks for the changes, it's better this way.