Bug 126319 - FILESAVE: exporting selection to bitmap formats produces distorted output
Summary: FILESAVE: exporting selection to bitmap formats produces distorted output
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All All
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:7.4.0 target:7.3.2
Keywords: bibisected, bisected, regression
: 132590 146799 (view as bug list)
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
 
Reported: 2019-07-10 02:22 UTC by Christopher Alexander Chavez
Modified: 2022-02-21 14:44 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Test drawing used to produce example PNG files (9.81 KB, application/vnd.oasis.opendocument.graphics)
2019-07-10 02:23 UTC, Christopher Alexander Chavez
Details
PNG output for single text box (7.59 KB, image/png)
2019-07-10 02:24 UTC, Christopher Alexander Chavez
Details
PNG output for two text boxes (12.40 KB, image/png)
2019-07-10 02:24 UTC, Christopher Alexander Chavez
Details
PNG output for upper text box and circle (8.94 KB, image/png)
2019-07-10 02:25 UTC, Christopher Alexander Chavez
Details
PNG output for lower text box and circle (10.07 KB, image/png)
2019-07-10 02:26 UTC, Christopher Alexander Chavez
Details
Rectangle (ODG) (8.83 KB, application/vnd.oasis.opendocument.graphics)
2022-01-28 12:39 UTC, Rafael Lima
Details
Rectangle (PNG) (979 bytes, image/png)
2022-01-28 12:40 UTC, Rafael Lima
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Alexander Chavez 2019-07-10 02:22:18 UTC
Note that this issue also applies to Impress; not sure if I should have selected a different component.

Selecting objects and then doing File > Export, checking "selection", and saving to various bitmap image formats (bmp, png, jpeg, etc.) produces files that are distorted (i.e. incorrect aspect ratio): usually, the objects appear to be stretched vertically/compressed horizontally. Attempting to change the height/width options does not prevent this issue since changing one causes the other to be recalculated according to the (incorrect) aspect ratio.

Unfortunately, I'm not sure what the exact conditions for reproducing this are. At first, I believed this only occurred when selecting single text boxes, and not when selecting two text boxes or a text box plus a shape; but I have since been able to create distorted output for selections of multiple objects.

The attached examples are of a single text box, two offset identical text boxes, and each text box with a circle; all have some amount of distortion, but the single text box is the most noticeable example.

This issue seems to happen regardless of OS (have reproduced on Windows, Mac and Linux).

Earliest version I have tried so far which has this issue is 6.2.4; it does not appear to be present in 6.1.6 or earlier.
Comment 1 Christopher Alexander Chavez 2019-07-10 02:23:37 UTC
Created attachment 152694 [details]
Test drawing used to produce example PNG files
Comment 2 Christopher Alexander Chavez 2019-07-10 02:24:19 UTC
Created attachment 152695 [details]
PNG output for single text box
Comment 3 Christopher Alexander Chavez 2019-07-10 02:24:49 UTC
Created attachment 152696 [details]
PNG output for two text boxes
Comment 4 Christopher Alexander Chavez 2019-07-10 02:25:12 UTC
Created attachment 152697 [details]
PNG output for upper text box and circle
Comment 5 Christopher Alexander Chavez 2019-07-10 02:26:46 UTC
Created attachment 152698 [details]
PNG output for lower text box and circle
Comment 6 Regina Henschel 2019-07-10 22:09:45 UTC
It was OK in Version: 6.2.0.0.alpha0+ (x64)
Build ID: 215780a7eca23c1bfcde74958e10ae84ea12d506
CPU threads: 8; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-15_22:56:00
Locale: de-DE (en_US); Calc: CL

It is broken in Version: 6.2.0.0.alpha1+ (x64)
Build ID: bf4fc97131147d25b18d088023262c977f0b2787
CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-10_01:58:33
Locale: de-DE (en_US); UI-Language: en-US
Calc: CL

The glyphs are stretched to the box size, the space above and below the glyphs is missing. If you insert the produced image and compare it with the source, you see the distortion immediately.
Comment 7 raal 2019-07-19 08:50:19 UTC
This seems to have begun at the below commit.
Adding Cc: to Armin Le Grand; Could you possibly take a look at this one? Thanks
 06599193348562f3e4878a9b149ad8caed7554fe is the first bad commit
commit 06599193348562f3e4878a9b149ad8caed7554fe
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Fri Aug 17 12:33:05 2018 -0700

    source sha:046df0a876b3d948bb1e14443c00c180bc8cccaa

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-08-16 20:20:47 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-08-17 21:27:40 +0200
commit 046df0a876b3d948bb1e14443c00c180bc8cccaa (patch)
tree 9619fa49b3f1b66302cbae973603f1c3f41ba3b0
parent bc28d51cb88c796da241d1ab914bbe6bb174cc49 (diff)
tdf#105998: Enhanced fix for MetafileToBitmap at better place
Comment 8 Armin Le Grand 2022-01-04 14:48:09 UTC
Mismatch of B2DRange of Text - in principle it's ok to creater the bitmap as small as possible what the used primitive render service is capable of. At the same time the size gets calculated based on the SdrObjects, where the text one has invisible borders.
Hard to decide what to do
(a) Accept smallest possible BM to create, adapt created size to it
(b) Somehow extend to SdrObject & invisible TextBorders, accept bigger result
Hmmm...
Comment 9 Armin Le Grand 2022-01-05 10:25:59 UTC
Maybe double to tdf#132590
Comment 10 Armin Le Grand 2022-01-24 09:15:07 UTC
*** Bug 146799 has been marked as a duplicate of this bug. ***
Comment 11 Armin Le Grand 2022-01-24 09:16:01 UTC
*** Bug 132590 has been marked as a duplicate of this bug. ***
Comment 12 Armin Le Grand 2022-01-26 10:32:24 UTC
Taking a look. Comment 8 shows the basic dilemma. It gets triggered at GraphicExporter::GetGraphic in svx/source/unodraw/UnoGraphicExporter.cxx which calls GetBitmapFromMetaFile.
That gets the correct sizes at the metafile in rMtf.GetPrefSize() and rMtf.GetPrefMapMode(). Problem is that this then gets corrected using

        tools::Rectangle aHairlineRect;
        const tools::Rectangle aRect(rMtf.GetBoundRect(*Application::GetDefaultDevice(), &aHairlineRect));

which then falls back to the 'real' graphical bounds cutting off the (unused, empty) borders from the TextObject (as in comment 8).

This happens due to 046df0a876b3d948bb1e14443c00c180bc8cccaa:
tdf#105998: Enhanced fix for MetafileToBitmap at better place

as detected by comment 7. Checking that one shows that this was/is needed to get the hairline bottom/right problem solved. This means that it is intended to expand the BoundRect, not shrink it. This is a good possible fact for a fix. Checking this...
Comment 13 Armin Le Grand 2022-01-26 15:38:34 UTC
That stuff is really picky due to Metafile usage, should really be converted to primitives to make it more stable...
For now I have a working correction that now handles hairlines on edges correctly and individually for all four possibilities. This is needed for the example file - when any text and the circle is selected, for the circle hairline correction is needed for top/right, but not for left/bottom.
But it also has o work with former example from tdf#105998. Additionally, moving it dependent on TopLeft from Rectangle from rMtf.GetBoundRect is wrong and possibly removes empty edges like from TextBoxes.
Doing more extensive checks with adapted version...
Comment 14 Armin Le Grand 2022-01-26 17:10:00 UTC
Fix on https://gerrit.libreoffice.org/c/core/+/129002
Comment 15 Rafael Lima 2022-01-26 19:14:38 UTC
(In reply to Armin Le Grand from comment #14)
> Fix on https://gerrit.libreoffice.org/c/core/+/129002

Thanks for taking care of this bug. I ran a few tests and it seems the proposed patch fixes the aspect ratio issue.

However it does not fix the issues reported in bug 132590 (marked as duplicate of this bug). If you create a rectangle with borders, select it and export the selection to PNG, the right and bottom lines will be cropped.

Are you planning to fix this issue as well? Or will it be fixed in an upcoming patch?
Comment 16 Armin Le Grand 2022-01-27 09:05:03 UTC
(In reply to Rafael Lima from comment #15)
> However it does not fix the issues reported in bug 132590 (marked as
> duplicate of this bug). If you create a rectangle with borders, select it
> and export the selection to PNG, the right and bottom lines will be cropped.

That is strange - I checked that tdf#105998 still works - it has exactly that scenario in it's bugdoc (simple.odg) and hat works here with my fix. Could you try that one, please?
Comment 17 Armin Le Grand 2022-01-27 15:25:07 UTC
> However it does not fix the issues reported in bug 132590 (marked as
> duplicate of this bug). If you create a rectangle with borders, select it
> and export the selection to PNG, the right and bottom lines will be cropped.

Just to make sure I did a Win ersionm too, also looks good. I use the "111.odg" file from that task, select upper, export, insert, all okay AFAIS...
Comment 18 Commit Notification 2022-01-28 08:46:47 UTC
Armin Le Grand (Allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5a67220831b994c4ecb83d93333eb76bffb88015

tdf#126319 Correct area(s) on selection export

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Rafael Lima 2022-01-28 12:39:58 UTC
Created attachment 177874 [details]
Rectangle (ODG)

> That is strange - I checked that tdf#105998 still works - it has exactly
> that scenario in it's bugdoc (simple.odg) and hat works here with my fix.
> Could you try that one, please?

Hi Armin, I built LO from source again (including your recent commit) and I'm still getting the export error.

See the attached ODG file with a simple rectangle. Do the following:
1) Select the rectangle
2) Export the selection as PNG
3) The exported rectangle misses the bottom and right borders

I'll attach below the resulting PNG using my PC.

Build info:
Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 124059f64a87d8074a0be32d6cc5f74c71bf836e
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: CL
Comment 20 Rafael Lima 2022-01-28 12:40:47 UTC
Created attachment 177875 [details]
Rectangle (PNG)

This is the exported PNG. Note that the bottom and right borders are cropped.
Comment 21 Armin Le Grand 2022-01-28 14:09:00 UTC
(In reply to Rafael Lima from comment #20)
> Created attachment 177875 [details]
> Rectangle (PNG)
> 
> This is the exported PNG. Note that the bottom and right borders are cropped.
Wow, thanks for that example :-) Indeed, top-left is one pixel transparent, while bottom-right is missing. SIGH. That means adding that half-pixel to the logic coordinates might be position-dependent and would have to be aligned with real pixel-changes in logical coordinates.
Oh how I wish that would be on primitives already, that would be so much simpler...
Comment 22 Armin Le Grand 2022-01-31 09:52:30 UTC
I found out why it fails with your example, it's pretty simple: The bools to detect hairlines bHairlineRight, bHairlineBottom, bHairlineLeft and bHairlineTop fail, so the correction is not done.
They fail since that lines are not hairlines - you can check (or probably knew) that these have a LineWidth of 0.35mm.
That is good and ok, getting away from hairlines which are a stay-over from non-AA times where lines could not be painted taller than one pixel is fine.
But that whole correction mechanism will then fail the same amount more often that those lines are no longer 'hairlines' at all.
Thus that correction mechanism itself just did not age well with going more to non-hairlines in the code. Since that change is good, we need to find a better way to detect when that correction is needed and how to do it...
Comment 23 Armin Le Grand 2022-01-31 18:42:14 UTC
It was now unavoidable to do bigger changes, I changed the range calculation to primitives which makes it reliable for all cases. I did not change the paint itself, hat would be too much for now.
I also removed the detection of hairlines at the extremes of a metafile since that is not sufficient anymore as a base for fixes. Hairlines are less used (see above) what is good. Eventual further changes will also need changes in the direction of primitives to get to a better base for corrections.
Comment 24 Armin Le Grand 2022-02-01 13:36:31 UTC
(In reply to Rafael Lima from comment #20)
> This is the exported PNG. Note that the bottom and right borders are cropped.

New version at https://gerrit.libreoffice.org/c/core/+/129235 - could you have a look please?
Comment 25 Commit Notification 2022-02-02 08:43:29 UTC
Armin Le Grand (Allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4d535c4f867d86d40786788e5e5c9fd061a65673

tdf#126319 Corrected bitmap creation from metafile

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 Rafael Lima 2022-02-02 12:10:54 UTC
> New version at https://gerrit.libreoffice.org/c/core/+/129235 - could you
> have a look please?

Hi Armin, sorry I did not have time to check it earlier.

I have just tried your patch and the exported rectangle worked perfectly. I also made additional tests with more shapes and all exported correctly.

Thanks for your great work! This was an issue I always struggled with using LO Draw. I'm certain many users will be pleased with this fix!
Comment 27 Armin Le Grand 2022-02-03 09:22:22 UTC
> Hi Armin, sorry I did not have time to check it earlier.
No problem, thanks for Checking and delivering that good example that lead me to the right way to fix it :-)
Comment 28 Commit Notification 2022-02-08 15:45:11 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/fd2f6282cb898f4a356ea8acf3dd1129f09fc1e1

tdf#126319: sd_png_export_tests: Add unittest

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 29 Commit Notification 2022-02-11 19:36:02 UTC
Armin Le Grand (Allotropia) committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/b3712c66978012ea49479bf3ac04bf8355d2a885

tdf#126319 Correct area(s) on selection export

It will be available in 7.3.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 30 Commit Notification 2022-02-11 19:37:12 UTC
Armin Le Grand (Allotropia) committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/a9f6d98859321e1b9029acc0c6e9347f4c1cf3b7

tdf#126319 Corrected bitmap creation from metafile

It will be available in 7.3.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.