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 312179 - .png export has invalid scale info
.png export has invalid scale info
Status: RESOLVED NOTABUG
Product: dia
Classification: Other
Component: exports
0.94
Other All
: Normal normal
: ---
Assigned To: Dia maintainers
Dia maintainers
Depends on:
Blocks:
 
 
Reported: 2005-08-01 00:58 UTC by alan ezust
Modified: 2005-08-09 21:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description alan ezust 2005-08-01 00:58:37 UTC
Please describe the problem:
Some rendering packages require png files to have proper scale information.
DIA does not save this to its .png files.

From http://lists.oasis-open.org/archives/docbook-apps/200507/msg00142.html
Hello Alan,

This PNG is broken so the bug is in DIA. Some graphic formats
supports internal information about image resolution and some does
not. PNG can have such information and, if present, this information
should be contained in pHYs chunk of the image data. DIA does writes
this data chunk into PNG, but fails to specify proper resolution for
an image (vertical resolution is set to 0). So the processing of such
image depends on the particular application fall-back strategy. Some
application may decide to treat such image as having no information
about the resolution at all, other will rise the error. I bet you are
using very old version of XEP (that followed first strategy), because
modern version of XEP will reject such image with appropriate error
message. 

Note that actual size of the image without intrinsic resolution will
be determined individually by each application depending on default
resolution it uses. XEP default is 120 DPI (you can read more about it
in the Section "5.1. Bitmap Graphics" of "XEP Reference").

Conclusion: fix DIA or use some tool to postprocess those PNGs (after
I've re-saved your 'account.png' using XnView it worked fine with
XEP). If you have image without intrinsic resolution - specify image
dimensions explicitly in your document.

Best regards,
Alexander Peshkov                             mailto:peshkov@renderx.com
RenderX


Steps to reproduce:
1. Try rendering a .PNG image in renderX's XEP (xml to PDF processor)
2. 
3. 


Actual results:
the image looks HUGE

Expected results:
It should look the correct size

Does this happen every time?
yes

Other information:
Comment 1 Hans Breuer 2005-08-05 15:48:25 UTC
Exporting my standard file render-test.dia to PNG makes
The GIMP show exactly the expected print size.

Here: 282x228 mm for a two page (A4) document. It appears
to me that the physical resolution is calculated right,
but the user expected something different. Note: the 
resolution is calculated from the paper info.
Comment 2 alan ezust 2005-08-09 20:20:37 UTC
From: Michael Smith <smith@xml-doc.org>
To: Alan Ezust <alan.ezust@gmail.com>
Cc: Alex Peshkov <peshkov@renderx.com>, docbook-apps@lists.oasis-open.org
Date: Aug 8, 2005 11:32 PM
Subject: Re: Re[2]: [docbook-apps] XEP and .PNG images created with Gnome's DIA
Reply | Reply to all | Forward | Print | Add sender to Contacts list | Trash
this message | Report phishing | Show original
Alan Ezust <alan.ezust@gmail.com> writes:

> I filed the bug, and it was closed as "not a bug".
>
> apparently there is still a bug in XEP with regards to rendering PNG files.
> It does not read the correct resolution from the file.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=312179

XEP can't read the correct resolution from the file if the
resolution information in the file is not correct. :)

The bug is in your PNG file.

Try installing pngcheck(1) or some other utility that can display
chunk-level information from PNG files, and use that to view the
data in the pHYs chunk of your account.png file. What you will see
is something like the following.

 $ pngcheck -v account.png
 File: account.png (5299 bytes)
   chunk IHDR at offset 0x0000c, length 13
     217 x 182 image, 24-bit RGB, non-interlaced
   chunk sBIT at offset 0x00025, length 3: red = 8 green = 8 blue = 8
   chunk pHYs at offset 0x00034, length 9: 2000x0 pixels/meter
   chunk IDAT at offset 0x00049, length 5206
     zlib:  deflated, 32K window, default compression
   chunk IEND at offset 0x014ab, length 0
 No errors detected in account.png (95.5% compression).

Note the "chunk pHYs at offset 0x00034, length 9: 2000x0 pixels/meter"
line. That specifies the horizontal/vertical (x and y) physical
resolution of your image. A y value of 0 makes no sense. The y
value should be the same as the x value, if you want most apps to
be able to handle it correctly.

So if you created that account.png file using some version of DIA,
then it seems there is a bug in whatever version of DIA you're
using. What version is it? When I use the v0.94 version of DIA on
Linux, it exports PNG images correctly, with both the x and y
values in the pHYs chunk set to the same value (2000).

Try opening and resaving your account.png file in the GIMP or some
other image-edting app. What you'll see afterwards for the pHYs
chunk is something like this:

 chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi)

So the GIMP has changed/corrected the data in the pHYs chunk --
because the "2000x0" data it found there is not usable. If it does
find usable data in the pHYs chunk, it will not change it (unless
of course you explicitly set a different resolution before you
save the file).

 --Mike
- Show quoted text -

> On 7/18/05, Alexander Peshkov <peshkov@renderx.com> wrote:
> >
> > Hello Alan,
> >
> > This PNG is broken so the bug is in DIA. Some graphic formats
> > supports internal information about image resolution and some does
> > not. PNG can have such information and, if present, this information
> > should be contained in pHYs chunk of the image data. DIA does writes
> > this data chunk into PNG, but fails to specify proper resolution for
> > an image (vertical resolution is set to 0). So the processing of such
> > image depends on the particular application fall-back strategy. Some
> > application may decide to treat such image as having no information
> > about the resolution at all, other will rise the error. I bet you are
> > using very old version of XEP (that followed first strategy), because
> > modern version of XEP will reject such image with appropriate error
> > message.
> >
> > Note that actual size of the image without intrinsic resolution will
> > be determined individually by each application depending on default
> > resolution it uses. XEP default is 120 DPI (you can read more about it
> > in the Section "5.1. Bitmap Graphics" of "XEP Reference").
> >
> > Conclusion: fix DIA or use some tool to postprocess those PNGs (after
> > I've re-saved your 'account.png' using XnView it worked fine with
> > XEP). If you have image without intrinsic resolution - specify image
> > dimensions explicitly in your document.
> >
> > Best regards,
> > Alexander Peshkov mailto:peshkov@renderx.com
> > RenderX
> >
> >

--
Michael Smith
http://sideshowbarker.net/
Comment 3 alan ezust 2005-08-09 20:23:39 UTC
here's the link to the image in question:
http://lists.oasis-open.org/archives/docbook-apps/200507/png00000.png
Comment 4 Hans Breuer 2005-08-09 21:24:35 UTC
There seems to be a problem with your PNG - as you have had others analyze.
Looking once more on it probably wont reveal any new information. Still
my testing did not allow me to reproduce the issue. That's what I've
described above.

Note: there are potentially *three* PNG export filters in Dia - one of 
them marked experimental. Without a way to *reproduce* your problem we 
wont be able to help you. You may want to try to reproduce the issue
yourself - and tell us which PNG variant you used.
Comment 5 alan ezust 2005-08-09 21:52:59 UTC
my apologies. now that I have pngcheck, I can verify for myself that indeed, the
more recently created .png files (from dia) do have the correct pixels/meter.
this other file must have been created by an older version.