Bug 91768 - FILESAVE : png export changes object size
Summary: FILESAVE : png export changes object size
Status: RESOLVED DUPLICATE of bug 122155
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Graphics-Export Image-DPI
  Show dependency treegraph
 
Reported: 2015-05-31 07:43 UTC by Topi
Modified: 2024-06-18 06:14 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (434.63 KB, image/png)
2015-05-31 07:43 UTC, Topi
Details
Sample ODG file (8.40 KB, application/vnd.oasis.opendocument.graphics)
2021-12-06 23:05 UTC, Rafael Lima
Details
Resulting PNG file (1.06 KB, image/png)
2021-12-06 23:13 UTC, Rafael Lima
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Topi 2015-05-31 07:43:56 UTC
Created attachment 116189 [details]
screenshot

Steps to Reproduce:
 1. Draw a rectangle and select it
 2. Export to PNG ("selection" disabled)
 3. Change DPI to eg 600 and restore original page size
 4. Press ok
 5. Open exported file with favourite editor (like gimp)  
 6. Measure the size of the rectangle (I use the crop dialog in gimp for that)

Expected: Rectangle-size in both programs are measured to be equal
Actual: Rectangle-size differs

Additional Information: The size-difference might relate to the transparent area created by the export within the png image (see attachment)

Version: 4.3.6.2
Build-ID: d50a87b2e514536ed401c18000dad4660b6a169e
Comment 1 Buovjaga 2015-06-09 12:44:21 UTC
Reproduced.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: d28102b1ed0c31500bbc68453a7b7613bd2bfa06
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-09_01:06:39
Locale: fi-FI (fi_FI)
Comment 2 QA Administrators 2016-09-20 10:00:56 UTC Comment hidden (obsolete)
Comment 3 Julien Nabet 2020-07-10 10:29:38 UTC
in step 3, I'm not sure to understand "restore original page size" means.
Indeed, if I put back 21/29.7, LO calculates a huge size file.

Anyway, any better with a recent LO version? (last one is 6.4.5)
Comment 4 Buovjaga 2020-07-11 15:42:38 UTC
(In reply to Julien Nabet from comment #3)
> in step 3, I'm not sure to understand "restore original page size" means.
> Indeed, if I put back 21/29.7, LO calculates a huge size file.

Yep, I assume this is what was meant. Doesn't seem to be any better.

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: 57fedb272cfcad3436142dbe9eac2870e3c3e3d2
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 9 July 2020
Comment 5 Julien Nabet 2020-07-11 18:23:33 UTC
Buovjaga: a bit lost between initial dimensions, resolutions, the fact I can't put initial dimensions after having changed resolution because it seems to keep a ratio instead of just applying what I chose...
Anyway, since you reproduced this, let's let this one opened.
Comment 6 Buovjaga 2020-07-11 19:14:07 UTC
(In reply to Julien Nabet from comment #5)
> Buovjaga: a bit lost between initial dimensions, resolutions, the fact I
> can't put initial dimensions after having changed resolution because it
> seems to keep a ratio instead of just applying what I chose...
> Anyway, since you reproduced this, let's let this one opened.

I'm lost too. Maybe Topi should give a more detailed theoretical explanation of his expected vs. actual and we should ask some graphics wizard for opinions.
Comment 7 Buovjaga 2020-07-13 11:04:33 UTC
Comment from Noel on IRC:

most likely the PNG metadata is wrong
(the metadata says what physical dimension a pixel has)
Comment 8 Stéphane Guillou (stragu) 2021-08-29 13:56:25 UTC
Not Windows-only, also reproduced with:

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 9 Rafael Lima 2021-12-06 23:05:48 UTC
Created attachment 176749 [details]
Sample ODG file

Here's an ODG test file with a rectangle. I did the following steps:

1) Select the rectangle
2) Go to File - Export then check "Selection" and choose PNG format
3) In the PNG Options dialog, click "Modify resolution" and change it to 600 "pixels/inch"
4) Click OK

The resulting PNG has 350 x 156 pixels and it does not seem to have 600 dpi. I believe there's something wrong with this exported file.

I ran the tests on LO 7.3 beta.

Version: 7.3.0.0.beta1 / LibreOffice Community
Build ID: 436f14c25ec1847646b953cf13d0db4f7ca3be57
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded
Comment 10 Rafael Lima 2021-12-06 23:13:18 UTC
Created attachment 176750 [details]
Resulting PNG file

This is the resulting PNG file with 350 x 156 pixels.

Also note another export bug, since the bottom and left margins were not properly exported (see bug 132590).
Comment 11 Stéphane Guillou (stragu) 2024-06-18 06:14:32 UTC
(In reply to Julien Nabet from comment #5)
> a bit lost between initial dimensions, resolutions, the fact I
> can't put initial dimensions after having changed resolution because it
> seems to keep a ratio instead of just applying what I chose...
This poor UX is tracked in bug 144195.

(In reply to Topi from comment #0)
> Created attachment 116189 [details]
> The size-difference might relate to the transparent
> area created by the export within the png image (see attachment)
> Version: 4.3.6.2
I can reproduce the offset issue visible in the screenshot in 4.1.0.4 and 4.3.0.4 (without touching resolution or size settings): when exporting with transparency on, the resulting image has the size and resolution of the original page, but only shows the contents for a frame the size of the content area (i.e. page without margins) that has been moved to the top left of the image. This does not happen when transparency is off.
That offset issue was already resolved by 4.4.0.3, I believe it's bug 37682.

My understanding is that two issues described here are still current:
- the aspect ratio is changed because of regression in bug 122155 (which is likely linked to bug 89828)
- the metadata is wrong, likely bug 132959

I'd say let's mark as duplicate of bug 122155 (aspect ratio issue) and keep bug 132959 (metadata) in See Also.

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