Description: Save Image to PNG has no DPI written into the file Steps to Reproduce: 1. Select image. Format -> Image -> Save -> Choose file name & PNG & Press save 2. PNG options dialog popups up.. also having an resolution setting 3. Save the file -> open it with Irfan view -> No DPI Resolution within file 4. Repeat for image with DPI. Dialog shows 96 -> the file exported has 100 (also wrong) Actual Results: No DPI or wrong DPI Expected Results: DPI as in dialog Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded and in 4.4.7.2
Created attachment 160695 [details] Example file
Already confirmed by Regina
Same happens with compress, see bug 132961
I'm not an expert in informations of a image file, but when I export a *.png with LO 6.1.5.2 in 300dpi it shows an image for printing in 300dpi. GIMP sees this in the properties of the file. If I do the same with LO 6.4.6.2 it shows an image for printing in 72dpi. Tested this also with GIMP. So there must be a information inside the file which will show other program to set the right dpi in older LO-versions. Couldn't test LO 4.4.7.2 here, but tested LO 6.1.5.2 and there it works. So I would say it is an regression in the last 6.*-versions. All tests made with the attached *.odg-file. Exported the star with 300dpi and x=6cm y=6cm. My system: OpenSUSE 15.1 64bit rpm Linux.
Created attachment 168385 [details] Testfile for export
(In reply to Robert Großkopf from comment #5) > Created attachment 168385 [details] > Testfile for export You appear to have found another bug (or another facet) My PNG without DPI (initial sample) and you're drawing do export with DPI in 6.2 when using DRAW. The PNG without DPI doesn't export a DPI with Writer with 6.2 either.. (which was topic here) I copy/pasted my PNG from Writer to Draw with 7.1. It's not only lacking DPI. It's apparently even a thumbnail (640 x 480 pixels) instead of the source file. Similar kind of thing happens with the Star (it's low res image..)
I'd like to second Roberts remark. Exporting the same odg-File with LO 6.1 gives the following png information obtained by imagemagicks identify -verbose: Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 1183x925+0+0 Resolution: 118.3x118.3 Print size: 10x7.8191 Units: PixelsPerCentimeter Type: TrueColorAlpha ... Exporting the same file with LO 6.4 and 7.0 from LO website the header reads now: Image: TCP-Header.png Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 1183x925+0+0 Units: Undefined Type: TrueColorAlpha Obviously, the fields resolution, print size are missing and the field units is left undefined. Using the standard equation: no_of_pixels = dpi * inches the information in the new header format is not sufficient to deduce the size and/or the resolution. gimp, inkscape, imagemagick et al thus have to assume a resolution ... and choose the standard of 72. IMHO this looks really like a regression in the 6* series to me... BTW: platform for tests is Linux Mint 19.3
*** Bug 139152 has been marked as a duplicate of this bug. ***
Dear Telesto, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug is still the same in LO 7.4.3.2 on OpenSUSE 15.3 64bit rpm Linux.
*** Bug 132961 has been marked as a duplicate of this bug. ***
*** Bug 155521 has been marked as a duplicate of this bug. ***
Duplicate bug 155521 comment 1 reproduces in 4.1.0.
(In reply to WN from comment #7) > IMHO this looks really like a regression in the 6* series to me... This regression was introduced in 6.3 and is still present in master at 24.2. I set bug 139152 from "duplicate" back to "new" as the offending commit is identified there.
(In reply to Telesto from comment #0) I also tested in 4.4.7 with attachment 160695 [details] to check Telesto's findings. (No export dialog in that version.) I used this ImageMagick command to check the metadata: identify -verbose png44nodpi.png | head -10 - for top picture: no resolution, no print size, no unit: Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 640x480+0+0 Units: Undefined Colorspace: sRGB Type: TrueColorAlpha Base type: Undefined Endianess: Undefined - for bottom picture: Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 640x480+0+0 Resolution: 39.37x39.37 Print size: 16.256x12.192 Units: PixelsPerCentimeter Colorspace: sRGB Type: TrueColor The resolution does correspond to the original 100 DPI. (39.37*2.54) In 6.0 (when dialog became available), 7.0, and a recent master build at 24.2: - for top picture, target is 96 dpi: Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 640x480+0+0 Units: Undefined Colorspace: sRGB Type: TrueColorAlpha Base type: Undefined Endianess: Undefined - for bottom picture, target is 96 dpi: Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 640x480+0+0 Resolution: 39.37x39.37 Print size: 16.256x12.192 Units: PixelsPerCentimeter Colorspace: sRGB Type: TrueColor So resulting files are the same in 4.4, 6.0, 7.0 and 24.2. The difference is that the DPI settings displayed in the dialog available since 6.0 have no impact on resulting files. Exact same results if changing the DPI to e.g. 150 or reducing it to 50 in the dialog before exporting. (Which is bug 150310, currently duplicate of bug 144195.) So my conclusion is: - Export of image was OK in 4.4, because we had no resolution/size dialog: it matched the original file. - Now that we have the dialog, we notice that it does nothing when changing the DPI setting. I will review the duplicate here and in bug 144195, when I check how full-document export and compress dialog differ to the above. Using 6.0 as earliest version, as that's when the dialog appeared.
Appears to be OK Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 125fc2ce861c82592b261f2992c893b414396e56 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded
I tested with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5a4ab8cb3a3fbf15de11afc5d8876aaa8a7784c9 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and get the same results as version 24.2 in comment 15. What exactly did you test, Telesto?
(In reply to Stéphane Guillou (stragu) from comment #17) Well I'm surely mistaken. Not sure what I did. Side-note: The marking the status to FIXED is accidental. I'm blaming the bugtracker for it. I haven't exact steps, yet: it's something like pressing back button in browser when status is set to RESOLVED, WFM. Where RESOLVED remains, but secondary part (WFM) being reset to the top of the list (FIXED), if not reconfigured again. The reason for pressing back: posting failed (time-out) or something like that. I'm simply pressing post again after pressing back-button without checking...