Bug 132590 - Export selection cuts off pixels on the right side and at the bottom side
Summary: Export selection cuts off pixels on the right side and at the bottom side
Status: RESOLVED DUPLICATE of bug 126319
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-05-01 15:08 UTC by lhesse
Modified: 2023-02-04 19:15 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Exported rectangle image. (1.33 KB, image/gif)
2020-05-01 15:10 UTC, lhesse
Details
More information about the bug (61.15 KB, application/x-zip-compressed)
2020-05-02 18:26 UTC, lhesse
Details
Example file with shape and PNG exported one (15.55 KB, application/vnd.oasis.opendocument.graphics)
2020-05-02 20:01 UTC, Telesto
Details
Test-InGimp.png (128.03 KB, image/png)
2020-05-02 20:07 UTC, Bart
Details
PixelsOnTheRightAndBottom-inGimp.png" (130.33 KB, image/png)
2020-05-02 20:10 UTC, Bart
Details
BMP (574.81 KB, image/bmp)
2020-05-02 21:08 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lhesse 2020-05-01 15:08:59 UTC
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
Comment 1 lhesse 2020-05-01 15:10:41 UTC
Created attachment 160182 [details]
Exported rectangle image.

Here is an example of a rectangle I exported. The right and bottom pixel lines are missing.
Comment 2 Bart 2020-05-01 19:59:08 UTC
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.
Comment 3 Bart 2020-05-01 20:04:56 UTC
Oops, I forgot ...

If you upload
   "Unbenannt 1.odg"
then that also answers 
   "what's the size of your rectangle?" ;-)
Comment 4 lhesse 2020-05-02 18:26:41 UTC
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.
Comment 5 Telesto 2020-05-02 20:01:22 UTC
Created attachment 160246 [details]
Example file with shape and PNG exported one
Comment 6 Telesto 2020-05-02 20:02:31 UTC
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:
Comment 7 Bart 2020-05-02 20:06:22 UTC
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
Comment 8 Bart 2020-05-02 20:07:54 UTC
Created attachment 160247 [details]
Test-InGimp.png
Comment 9 Bart 2020-05-02 20:10:03 UTC
Created attachment 160248 [details]
PixelsOnTheRightAndBottom-inGimp.png"
Comment 10 Telesto 2020-05-02 20:49:43 UTC
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.
Comment 11 Telesto 2020-05-02 21:08:28 UTC
Created attachment 160253 [details]
BMP
Comment 12 Telesto 2020-05-02 21:50:11 UTC Comment hidden (obsolete)
Comment 13 Telesto 2020-05-02 21:50:47 UTC
@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.
Comment 14 Regina Henschel 2020-05-03 18:12:12 UTC
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.
Comment 15 Regina Henschel 2020-05-03 19:00:59 UTC
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
Comment 16 Bart 2020-05-03 19:50:03 UTC
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. ;-)
Comment 17 Buovjaga 2020-06-13 13:34:42 UTC
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.
Comment 18 Smyan Jaipuriyar 2020-09-23 05:14:52 UTC
*** Bug 134545 has been marked as a duplicate of this bug. ***
Comment 19 Buovjaga 2020-09-23 05:16:12 UTC
Based on the duplicate, looks like this is not Win-only after all. Not sure, why I could not reproduce on Linux.
Comment 20 Timur 2021-09-17 11:41:57 UTC
*** Bug 136584 has been marked as a duplicate of this bug. ***
Comment 21 Rafael Lima 2021-09-17 12:17:30 UTC
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.
Comment 22 Armin Le Grand 2022-01-24 09:16:01 UTC

*** This bug has been marked as a duplicate of bug 126319 ***