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
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)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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)
(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
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.
(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 from Noel on IRC: most likely the PNG metadata is wrong (the metadata says what physical dimension a pixel has)
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
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
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).