Description: Exporting a selected shape of 7x7 to any image format shows size of 7,01 cm in the export options dialog Steps to Reproduce: 1. open the attached file 2. Select the shape 3. File -> Export -> Selection.. 4. press save 5. Notice 7,01 instead of 7 Note: assuming DPI 96 Actual Results: 7,01 cm Expected Results: 7 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 05ff3d67d0e2e436406786c949eb7cfca107ba33 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
Created attachment 174753 [details] Example file
Also in 7.1 and in Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL and in Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89) and in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b if you change the resolution 1 dpi up/down and back.. size changes to 6,98 cm
Better STR 1. open the attached file 2. Select the shape 3. File -> Export -> Selection.. 4. press save 5. Notice 7,01 instead of 7 (assuming dimensions in CM) 6. With Pixel to Inch: Change DPI from 96 to 95 and back to 96 -> dimension changes 7. Close dialog 8. Follow step 1 - 4 again 9. Change Pixel to inch to Pixel to CM 10. Change DPI from in my case 37 to 38 & back to 37 11. Dimension become: 7,16 cm
@Regina You're better in math :-). Superficial I would say a round error. Does not happen with a 10x10 cm square or 5x5 cm square. But with 6x6 cm or 7x7 cm square
This is normal. You are saving a raster image file that must have an integral number of pixels in both dimensions. You define a resolution: > Note: assuming DPI 96 which means that each pixel is exactly 1/96 in ~ 0.264583 mm. Such an image may only have 264 or 265 pixels to approximate 7 cm. In first case, the resulting actual metric size would be 69.85 mm; in the second, it would be ~70.114 mm. That is correctly displayed to the user.
(In reply to Mike Kaganski from comment #5) > This is normal. > > You are saving a raster image file that must have an integral number of > pixels in both dimensions. You define a resolution: > > Note: assuming DPI 96 > > which means that each pixel is exactly 1/96 in ~ 0.264583 mm. > > Such an image may only have 264 or 265 pixels to approximate 7 cm. In first > case, the resulting actual metric size would be 69.85 mm; in the second, it > would be ~70.114 mm. That is correctly displayed to the user. Ah, however, - shifting goalposts a little - still confused why there is the variation.. * 7,01 cm on dialog initialization. And 6,98 cm after bumping DPI to 97 and back to 96. If this is a rounding should end up this way, please make it consistent. * And even worse in case of switching from DPI to Pixel to CM. Where moving 37 Pixel the CM up to 38 and back to 37 end up with 7,16 CM not 7,01 cm
(In reply to Telesto from comment #6) > why there is the variation.. > * 7,01 cm on dialog initialization. And 6,98 cm after bumping DPI to 97 and > back to 96. If this is a rounding should end up this way, please make it > consistent. This is reasonable. Please limit it to this. > * And even worse in case of switching from DPI to Pixel to CM. Where moving > 37 Pixel the CM up to 38 and back to 37 end up with 7,16 CM not 7,01 cm No it is fine. If you look above, I wrote: > You define a resolution: > > Note: assuming DPI 96 > > which means that each pixel is exactly 1/96 in ~ 0.264583 mm. You see that 96 pixels per inch doesn't mean some "round" number of pixels per cm: 96 PPI = 37.7952755905512... pixels per cm. When you switch from in to cm in the resolution, the control shows a rounded (down) value, but internally the resolution is still exactly 96 PPI - which is *correct*, because user might need just to check some different units without actually change the resolution. However, when user starts to *modify* the resolution using the new units, the new value is the integral number of pixels per unit - and when you select 37 again, it is true 37 pixels per cm, not the initial 37.7952755905512... which you started with. Hence the difference in the size - which is again OK.
(In reply to Mike Kaganski from comment #7) > You see that 96 pixels per inch doesn't mean some "round" number of pixels > per cm: 96 PPI = 37.7952755905512... pixels per cm. When you switch from in > to cm in the resolution, the control shows a rounded (down) value, but > internally the resolution is still exactly 96 PPI - which is *correct*, > because user might need just to check some different units without actually > change the resolution. However, when user starts to *modify* the resolution > using the new units, the new value is the integral number of pixels per unit > - and when you select 37 again, it is true 37 pixels per cm, not the initial > 37.7952755905512... which you started with. Hence the difference in the size > - which is again OK. Sorry, for me needing such an expansive answer; mea culpa The dialog would be more self-explanatory if the spinbox did show some digits after the comma (Corel Paintshop has 3). This would explain the result by itself. And make it possible to input stuff behind the comma. If you touch the spinbox you lose the Dots per CM equivalent of say 96 DPI and you can't go back.. Yes, switching to DPI and go back to CM.. Note: personally I dislike using pixels per cm, so not something affecting me per se..