Description: When I export a selection in LibreOffice Draw, the right and bottom pixel line are removed in the exported image. Steps to Reproduce: 1. Open LibreOffice Draw 2. Select the rectangle shape on the left menu 3. Draw a rectangle on the sheet and make sure it is selected 4. Choose File->export from the main menu 5. Check the "selection" option right above the buttons 6. Click "save" 7. Click "ok" 8. Open the exported image in an image viewer of your choice Actual Results: Image with missing pixel lines on the right side and at the bottom. Expected Results: Image that consists of ALL selected pixels. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.4.2.2 (x64) Build-ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU-Threads: 4; BS: Windows 10.0 Build 18362; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL
Created attachment 160182 [details] Exported rectangle image. Here is an example of a rectangle I exported. The right and bottom pixel lines are missing.
I'm trying to recreate the image that you got. At first the things that I get on my screen look as expected. So I want to do it exactly the way you did. If you have the rectangle in Draw and if you right-click and select "Position and Size ..." then what is the size of your rectangle? If needed, feel free to make a new rectangle. I just need to have an impression of the size of the rectangle that you made and saved. If you export it, then what are the values for the Width, Height and Resolution? Thanks! PS: I'm not a developer. I'm a user myself and I submitted a few bug reports. I'm trying to confirm the bugs that other people reported here.
Oops, I forgot ... If you upload "Unbenannt 1.odg" then that also answers "what's the size of your rectangle?" ;-)
Created attachment 160235 [details] More information about the bug Here are some images of the position and size of the rectangle and the export settings I used. The rectangle itself is in test.png. You see the top and left margin is different from the bottom and right margin.
Created attachment 160246 [details] Example file with shape and PNG exported one
Not 2 corners, but all corners are affected, however, most obvious at the right side and at the bottom side Version: 7.0.0.0.alpha0+ (x64) Build ID: b8fb7ecd9cdbe1898c41eaecd9894df8e8f01e25 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc:
Now I get closer to the result that you have. If I use version 6.4.3.2, the top and left edge are the same as the bottom and right edge, but ... entirely on top I have a transparent edge of one pixel high, and entirely at the left there's a transparent edge of one pixel wide. When I use 7.0 it crashes, but that's what alpha versions are for, to test them before they're released. ;-) (FUN, now I have a bug to report myself. :-D ) When I restart 7.0, I follow the same steps and I get the same result as with 6.4.3.2. To compare the results yourself, please check attachments "Test-InGimp.png" (your exported image) and "PixelsOnTheRightAndBottom-inGimp.png" (my exported image) You are using 6.4.2.2 and if you think that the result that I had is better, then give it a thought to upgrade to 6.4.3.2. (But that's up to you.) PS: Gimp compares to Photoshop. I actually like it better than Photoshop. It's available on Linux and I believe also on Windows. ~~~ Here are the versions that I used: Version: 6.4.3.2 Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Version: 7.0.0.0.alpha0+ Build ID: 4d03bd252274308f64332e7c0523068c38ac684a CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-04-26_05:59:56 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 160247 [details] Test-InGimp.png
Created attachment 160248 [details] PixelsOnTheRightAndBottom-inGimp.png"
Version: 7.0.0.0.alpha0+ (x64) Build ID: b8fb7ecd9cdbe1898c41eaecd9894df8e8f01e25 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: PNG/Tiff have small borders No format has the 'actual' dimensions of 12,25 x 12,50. Most of the time 12,59x10,85 Borders are a lot better with Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL Dimensions probably also off. See 3.3.0 Results with: LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 SVG: - Border look the same as in 7.0 PNG - Bad quality export - Dimensions totally (17,39cm x 27,70 cm) PNG: - Looks the same as in 4.4.7.2 - Has the same oversized issue (12,60x10,85) Expected: 12,25 x 12,50) - Bad quality export BMP: - Proper size - Proper dimensions - Bad quality SVM - Oversized (12,60x10,85) - Proper quality - Borders OK JPG - Again different dimensions: 12,62cm x 10,87cm - Bad quality export - Borders look OK Adding bibisect request to for the 'improved' borders.
Created attachment 160253 [details] BMP
@Regina As the expert on image dimensions/resolution. I'm getting slightly insane related to image resolution/ screen resolution/ image size 1. Open attachment 160246 [details]. It has a shape in it of 12,25cm x 10,50cm. I exported the shape with Lib 7.0 in PNG format and imported it again dimensions shown are 12,46 x 10,72 cm (and borders a cropped, bug) I exported the same file SVG format in LibO 7. It shows as 12,63 cm x 10,88 cm (won't open in Irfan View/Corel) but has exactly the same dimensions as the shape (12,25 x 10,50 cm). If have also export it as BMP format (attachment 160253 [details] (did it with LibO 3.0, but difference is 2 pixels). The resolution is embedded (96x96 DPI). Shows up in LibO as 12,60 x 10,85cm (same as Irfan View) is a little smaller compared to the 12,25cm x 10,50cm.
I think, we have two different bugs here. 1) Metric size in the dialog is wrong: I use a rectangle with size 70mm×40mm without line. If I set 120dpi and 70mm width, the size in the dialog is set to 69.98mm×40.05mm and the resulting image has 333×190 pixels. If I use the next smaller value in the dialog, that is possible to get a height under 40mm, the dialog allows setting 69.77mm×39.84mm. That will result in 331×189 pixels. The correct pixels for 70mm×40mm at 120dpi would be 331×189 pixels, which calculating back results in 70.00616mm×40.005mm. So the dialog should use 70.01mm×40.01mm. That problem is inherit from OpenOffice. It is a minor bug, because setting size in pixels in the dialog is possible in LibreOffice. 2) Considering the line width is wrong. Now I use a rectangle with size 70mm×40mm with 20mm line width with rounded corners. Because the line is half inside, half outside the nominal size, the actual size is 90mm×60mm. That would result in image size of 425×283 pixels at 120dpi. That is shown in the dialog, if you use pixels as unit. But the resulting image has only the 70mm×40mm part with half of the line width. The part outside, with the rounded corners is missing. The shape is cropped. Because of the settings in the dialog, this cropped part is scaled to 90mm×60mm. That is a severe error in the export, and it is made by LibreOffice. AOO exports the part outside too. The "missing pixel" here is in first place no rounding problem, but a principle wrong export of thick lines. So before looking whether there is an additional rounding problems, that "thick line" bug has to be fixed.
Shape is not cropped in Version: 6.1.4.2 (x64) Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 8; OS: Windows 10.0; UI render: GL; Locale: de-DE (en_US); Calc: CL It is cropped in Version: 6.2.5.2 (x64) Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: threaded
I think that the other users here have more expertise about images than me. My contributions will be more useful elsewhere and I'm unsubscribing here. ;-)
Bibisected with win32-6.2 to https://git.libreoffice.org/core/+/046df0a876b3d948bb1e14443c00c180bc8cccaa%5E!/ tdf#105998: Enhanced fix for MetafileToBitmap at better place Adding Cc: to Armin Le Grand I don't repro this on Linux.
*** Bug 134545 has been marked as a duplicate of this bug. ***
Based on the duplicate, looks like this is not Win-only after all. Not sure, why I could not reproduce on Linux.
*** Bug 136584 has been marked as a duplicate of this bug. ***
Still present in: Version: 7.2.1.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.2.1~rc2-0ubuntu0.21.04.1~lo1 Calc: threaded (In reply to Buovjaga from comment #19) > Based on the duplicate, looks like this is not Win-only after all. Not sure, > why I could not reproduce on Linux. I have had this bug since I've been using LibreOffice, for almost 3 years now, both on Gtk and Kf5. The best way to reproduce it is to create a rectangle and set a large line width (f.i. 3 pt to make the export error more noticeable). Then select the rectangle and Export only the selection. You'll notice that the bottom and right borders are cropped as though LO did not consider the external size of the shape.
*** This bug has been marked as a duplicate of bug 126319 ***