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.
Created attachment 152694 [details] Test drawing used to produce example PNG files
Created attachment 152695 [details] PNG output for single text box
Created attachment 152696 [details] PNG output for two text boxes
Created attachment 152697 [details] PNG output for upper text box and circle
Created attachment 152698 [details] PNG output for lower text box and circle
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.
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 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
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...
Maybe double to tdf#132590
*** Bug 146799 has been marked as a duplicate of this bug. ***
*** Bug 132590 has been marked as a duplicate of this bug. ***
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...
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...
Fix on https://gerrit.libreoffice.org/c/core/+/129002
(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?
(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?
> 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...
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.
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
Created attachment 177875 [details] Rectangle (PNG) This is the exported PNG. Note that the bottom and right borders are cropped.
(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...
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...
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.
(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?
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.
> 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!
> 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 :-)
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.
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.
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.
*** Bug 134545 has been marked as a duplicate of this bug. ***
*** Bug 136584 has been marked as a duplicate of this bug. ***
*** Bug 158446 has been marked as a duplicate of this bug. ***