Description: the exported PNG loss the right scale Steps to Reproduce: 1. open the attached .odg that is 32x22 cm with 1 cm border, so has 30x20 cm area rectangle 2. Go to pag.1, export as so: 3. menu File, Export..., 4. File format: PNG, Save 5. Modify resolution: 300 pixels/inch 6. Modify dimensions, Width: 32 cm 7. the Height is set to 22 cm (so form factor is page not area rectangle) 8. OK Actual Results: the exported image is wrong, see attach "shape20x30cm_scale1:1_libreoffice7.2margin32x22.png" It has: 1. the right canvas extention 3786x2603 px 2. the right form factor 3. the image miss the 1 cm page border (may be OK) 4. the 30x20 cm (3543x2362 px) rectangle is stretched to 32x22 cm (3786x2603 px) Note: This does not happen if the page has no border, so 30x20 cm Expected Results: export a rectangle sized 30x20 cm (3543x2362 px) without border OR export a rectangle sized 30x20 cm (3543x2362 px) with 1 cm border so 32x22 cm (3786x2603 px Reproducible: Always User Profile Reset: No Additional Info: knowing that the exported PNG does not have the border, one can try to selecting: 5. Modify resolution: 300 pixels/inch 6. Modify dimensions, Width: 30 cm 7. the Height is set to 20.63 cm (so form factor is page not area rectangle) but the exported PNG has wrong form factor, so is worse In both cases the exported PNG is unusable as lost the right scale
Created attachment 174616 [details] test case
Created attachment 174617 [details] export as 32x22 cm
Created attachment 174618 [details] export as 30x20.63
The dimensions I get for the exported image are 4940 x 3396. Not sure what else to comment. I don't think you are supposed to be using both Modify dimensions and resolution as they are radio buttons that exclude each other. Arch Linux 64-bit Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495 CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 25 May 2022
If you ever select only dpi or size in mm, you will always get a un-useful image, because LibreOffice cannot know how many output pixels need in the vector to raster conversion. By definition the WxH [pixels] is the results of dpi [pixel/inch] x size [inch], so you have to define both, I think this is normal for a vector program. If you select only the output resolution 300 dpi, with this reference "test_case", you got an image sized 1210x832 pixels, that at 300 dpi, has a size of 102x70 mm If you select only the output size to 320 mm wide, with this reference "test_case", you got an image sized 1210x832 pixels, that at 300 dpi, has a size of 102x70 mm In both case it is wrong, as LibreOffice use the default of 96 dpi (grayed) to output for a monitor (not a printer) in case of 320 mm wide fixed size, and a default wide size of 102 mm in case of 300 dpi (printer range) fixed resolution. Seems to me that the only working method to export with the wanted pixels size is to specify both mm size and dpi resolution. But here export is not perfect and miss the border, so this bug report. Tested also on LibreOffice 7.2.5.2 do the same
What are the settings you used to get the 4940 x 3396 pixels output image?
(In reply to Valerio Messina from comment #6) > What are the settings you used to get the 4940 x 3396 pixels output image? Same as yours: 5. Modify resolution: 300 pixels/inch 6. Modify dimensions, Width: 32 cm
(In reply to Valerio Messina from comment #5) > If you ever select only dpi or size in mm, you will always get a un-useful > image, because LibreOffice cannot know how many output pixels need in the > vector to raster conversion. > By definition the WxH [pixels] is the results of dpi [pixel/inch] x size > [inch], > so you have to define both, I think this is normal for a vector program. Pay attention to what happens when you modify the resolution and then switch to dimensions radio button: the width and height have changed. As you see, one of the options is always *disabled* based on which radio button is selected. You can't modify both independently.
take note that 320x220 mm at 300 dpi is an image sized 3780x2598 pixels, and not 4940x3396. What version of LO are you using? When you modify the resolution, LO adjust the size with a not know logic, this is why then I had to force the size in mm too. Then switching back to resolution, LO keep both size and resolution, and this work, but cut out the page border.
4940x3396 pixels @300dpi is 418x287 mm
(In reply to Valerio Messina from comment #9) > take note that 320x220 mm at 300 dpi is an image sized 3780x2598 pixels, and > not 4940x3396. What version of LO are you using? See comment 4
so seems the output image size changed from LO 7.2 to 7.4, and both are wrong. Do you get the 10 mm page border in the resulting PNG? Take note that 320x220 mm source page has an espect ratio of 1.45454545 periodic the 300x200 mm rectange in the source page has an espect ratio of 1.5 The image I got with LO 7.2 is 3786x2603 px, so aspect ratio of 1.45447560507 The image you got with LO 7.4 is 4940x3396 px, so aspect ratio of 1.45465253239 The output image is out of scale and streched too
(In reply to Valerio Messina from comment #12) > so seems the output image size changed from LO 7.2 to 7.4, and both are > wrong. > > Do you get the 10 mm page border in the resulting PNG? I don't understand what you mean, so can't answer. You can test with 7.4 yourself: https://dev-builds.libreoffice.org/daily/master/current.html
Created attachment 180393 [details] expected export without 10 mm page border expected export without 10 mm page border
Created attachment 180394 [details] expected export with 10 mm page border expected export with 10 mm page border
I attached the expected PNG export with and without the 10 mm page border (those are generated with GIMP, specifying both 300 dpi resolution and image size 320 or 300 mm). The export you get with LO 7.4 is with or without the 10 mm page border? I will try by myself on Linux and Win too
I made some tests with a just installed Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: fd45045cc3029b41c02a2634e6fe2e5456f716ad CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3 Locale: it-IT (it_IT.UTF-8); UI: en-US Calc: threaded on Debian 11/x86_64 On first run, LO is configured with this export settings default: 1) Dimensions unit: cm 2) Resolution: 37 pixel/cm 3) Compression: 6 I changed to: 1) Dimensions unit: mm 2) Resolution: 96 pixel/inch 3) Compression: 9 Then perform some extractions with: . Modify resolution: 300 pixels/inch . Modify dimensions, Width: 320 mm . the Height is set by LO to 220.03 mm and width to 320.03 mm Results: - The output aspect ratio is the one of page, and not the one of the rectangle - the output images is sized: 3786x2603 px, that at 300 dpi, has a size of 320.55x220.39 mm - LO7.4 export to PNG the rectangle without the 10 mm page border (like LO7.2) and in contrast to export as PDF (but may be reasonable) So the 300x200 mm source rectangle is stretched to 320.55x220.39 mm in exported PNG This is out of scale of about 320/300=1.06 periodic, and worse the image is still with the wrong aspect ratio like was with LO7.2 This is still wrong but better than LO7.2 As the 10mm border is always omitted in exported PNG, I repeated the tests with: . Modify resolution: 300 pixels/inch . Modify dimensions, Width: 300 mm . the Height is set by LO to 206.26 mm while width remain to 300.00 mm Results: - The output aspect ratio is the one of page, and not the one of the rectangle - the output images is sized: 3549x2440 px, that at 300 dpi, has a size of 300.48x206.59 mm So the 300x200 mm source rectangle is stretched to 300.48x206.59 mm in exported PNG this is out of scale of about 300.48/300=1.0016 on X asis, 0.5 mm error maybe acceptable, but this is out of scale of about 206.59/200=1.03295 on Y asis, 6.59 mm error this is wrong. So the image is still with the wrong aspect ratio: original rectangle has 300/200=1.5 aspect ratio exported rectangle has 300.48/206.59=1.454475 aspect ratio Note 1: LO should export the drawing area (the 300x200 mm rectangle) keeping his aspect ratio, and not use the one of the page (that include the 10 mm border). Note 2: There are various approximation in LO compute for output pixels, that round the numbers in the wrong way too. Maybe caused by the use of a float instead of a double in some variables. Note 3: I cannot test on Win, as the only PC with Win I had access, is the company PC, but I cannot install an Alpha level application on it
(In reply to Buovjaga from comment #13) @Buovjaga can you please change the status from UNCONFIRMED?
(In reply to Valerio Messina from comment #18) > (In reply to Buovjaga from comment #13) > > @Buovjaga > can you please change the status from UNCONFIRMED? Sorry, I did not have time to understand it. I asked others to look at it in the QA chat and someone suggested that you could try an unstable build, which includes a new PNG exporter. As part of Google Summer of Code, PNG export is now handled by the libpng library. One way to test is to create an appimage: https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Automated_installation Or do the manual way https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Manual_installation
(In reply to Buovjaga from comment #4) > The dimensions I get for the exported image are 4940 x 3396. Not sure what > else to comment. I don't think you are supposed to be using both Modify > dimensions and resolution as they are radio buttons that exclude each other. > > Arch Linux 64-bit > Version: 7.4.0.0.alpha1+ / LibreOffice Community > Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495 > CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > Calc: threaded > Built on 25 May 2022 The same here in latest LO Draw 7.5 Paris, could you please look at it and say us your opinion?
(In reply to Roman Kuznetsov from comment #20) > (In reply to Buovjaga from comment #4) > > The dimensions I get for the exported image are 4940 x 3396. Not sure what > > else to comment. I don't think you are supposed to be using both Modify > > dimensions and resolution as they are radio buttons that exclude each other. > > > > Arch Linux 64-bit > > Version: 7.4.0.0.alpha1+ / LibreOffice Community > > Build ID: ff2b4bff61d2e1679bb525d754c960c48b81c495 > > CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) > > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > > Calc: threaded > > Built on 25 May 2022 > > The same here in latest LO Draw 7.5 > > > Paris, could you please look at it and say us your opinion? If I understand this bug correctly this shouldn't have anything to do with the png writer itself, but with the bitmap passed to the exporter when you export the .odg. Correct me if I'm wrong. Also as Buovjaga said I don't think you should use modify resolution and modify dimensions together. If you make changes to modify resolution then select modify dimensions and make changes there, shouldn't the modify resolution changes be ignored? Can you reproduce this bug while using only one of the two?
Didn't read the whole bug report, but bug 150310 maybe related or interfering with the bug here.
94 dpi = 94/25.4 = 3.7 px/mm 94 dpi = 94/2.54 = 37 px/cm 300 dpi = 300/25.4 = 11.811 px/mm 300 dpi = 300/2.54 = 118.11 px/cm aspect ratio=Width/Height same source drawing: 320x220 mm page , aspect ratio=1.4545... 300x200 mm rectangle, aspect ratio=1.5 All test made on Debian 11 Bullseye I take the time to build the appImage from daily sources: /opt/LibreOffice$ make_libreoffice_appimage.sh daily x86-64 N N N N Y /opt/LibreOffice$ LibreOfficeDev-7.5.0.0.alpha0_2022-10-09-x86_64.AppImage (tests 1-4 made setting size OR resolution) 1) set size: 32x22 cm (or 320x220 mm) resolution gray: 37 px/cm (or 3.7 px/mm) ==> PNG 1210x832 px, rectagle, aspect ratio=1.4543 2) set resolution: 37 px/cm (or 3.7 px/mm) ==> PNG 1210x832 px, rectagle, aspect ratio=1.4543 3) set resolution: 118 px/cm (or 11.811 px/mm) gray size change to 102.54x70.61 mm ==> PNG 1210x832 px, rectagle, aspect ratio=1.4543 4) set resolution: 300 dpi (or 11.811 px/mm) gray size change to 102.28x70.33 mm ==> PNG 1210x832 px, rectagle, aspect ratio=1.4543 expected results: 32x22 cm @37 px/cm is 1184x814 px, page , aspect ratio=1.4545... 30x20 cm @37 px/cm is 1110x740 px, rectagle, aspect ratio=1.5 ------------------------------------------------- (tests 5-7 made setting both resolution AND size) 5) set resolution: 118 px/cm gray size change to 102.28x70.33 mm set size Width: 300 mm Height resize to 206.27 mm (and not 200 mm) ==> PNG 3540x2434 px, rectagle, aspect ratio=1.454396 6) set resolution: 300 dpi gray size change to 102.28x70.33 mm set size Width: 300 mm Height resize to 206.26 mm (and not 200 mm) ==> PNG 3549x2440 px, rectagle, aspect ratio=1.4545 7) set resolution: 300 dpi set size Height: 200 mm Width resize to 290.87 mm (and not 300 mm) ==> PNG 3441x2366 px, rectagle, aspect ratio=1.4544 expected results: 32x22 cm @118 px/cm is 3776x2596 px, page , aspect ratio=1.4545... 30x20 cm @118 px/cm is 3540x2360 px, rectagle, aspect ratio=1.5 Comment: 1, 2, 3, 4) larger than expected on both WxH and aspect ratio is wrong 5) right Width, smaller that expected Height and so wrong aspect ratio 6) larger than expected on both WxH and aspect ratio is wrong 7) smaller that expected Width, larger than expected Height, wrong aspect ratio So best result is get with method 5), setting both resolution and size Width, at least one pixel size is right, but still got stretched PNG image Repeated the test with a page with no page border, and the exported rectangle is perfect, like happen with LO7.2 To me seems in no way this bug is fixed with LO7.5a, neither is better that 7.2 The bug is still unconfirmed
You insist on the fact that you have to select either only the size or only the resolution, but for the definition: px = inch * dpi = mm * dpmm to find out which pixel size to generate for the PNG, LibreOffice will always need two data: size and resolution. In fact, when you create (or resize) an image in GIMP (but also with Inkscape, Scribus or other graphics programs), two quantities are always specified to define an image, pixel and DPI, or size mm and DPI (maybe one is set at default but changeable), so that the third is calculated with the formula above. The fact that the two voices are in alternate with LO, can be a GUI bug itself. Or perhaps the designer wanted to undergo that when changing the resolution, it means that the size must be kept by default to that of the page (or to the size of the area without border), but, for unknown reason, as now LO change that with an unknown logic. If changing the resolution, LO would keep the output size to the size of the area without border, in the simplest case, it would not be necessary to set both. In any case, in the most general case of export, both items can be specified by the user (with the dimension default to that of the area without edge).
older version of LO (and current AOO) let select both quantities (size and resolution) at the same time in export dialog