Description: LO doesn't handle DrawImagePoints SrcRect properly. Steps to Reproduce: Open attached EMF sample. Actual Results: LO draws a piece of green rectangle in the top left corner and blue square in the middle of the image. Expected Results: It should draw green square of the same size as a blue one on the top part of the image. Reproducible: Always User Profile Reset: No Additional Info: In this case DrawImagePoints deals with an ObjectImage of the Metafile type. LO reads SrcRect and uses in in aGDI.Clip call, however it has wrong or no effect depends on the specific values provided. This was identified during analysis of EMF+ part of the issue with a file from tdf#59814. Solving this problem should also have a positive impact on tdf#59814.
Created attachment 173012 [details] EMF sample with a problem
Created attachment 173013 [details] Inner EMF/EMF+ inserted into main sample (for a reference)
Created attachment 173014 [details] Screenshot with a sample opened in LO 7.3alpha and MS Paint
Created attachment 173015 [details] How it probably should work for a simple translation case
Confirmed with: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 94d552f94b427f884c004dba5d4619ecf729d605 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-18_13:30:27 Calc: threaded Same with: Version: 7.2.0.0.beta1 / LibreOffice Community Build ID: c6974f7afec4cd5195617ae48c6ef9aacfe85ddd CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same result using the command: libreofficedev7.3 --headless --convert-to png *.emf
Created attachment 173038 [details] EMF+ sample with embedded bitmap As per Bartosz code for the two are quite similar --> keeping it in one bug.
Created attachment 173039 [details] Screenshot for EMF+ with embedded bitmap: LO7.3alpha vs MS Paint
> EMF+ sample with embedded bitmap It also scales the cropped picture by 2 in each direction.
Created attachment 173040 [details] JPEG embedded into EMF+ with bitmap sample
Created attachment 173042 [details] EMF+ sample with bitmap cropped to the cell with digit 5 in it It works almost fine in LO except that right and bottom border of the 'cell' with digit 5 are not present. SrcRect should be "inclusive" but LO cropped one pixel too early.
Created attachment 173043 [details] Screenshot for EMF+ with embedded bitmap and crop: LO7.3alpha vs MS Paint
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4992780d2bc996c111b333549314d72f6891308d EMF+ tdf#142941 Fixes for SrcRect in DrawImagePoints It will be available in 7.3.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.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/032b00382f654962ec787029b3a887f9efbd2a3d EMF+ tdf#142941 Fixes for SrcRect in DrawImagePoints It will be available in 7.2.0.0.beta2. 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.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3adfb2d35bb34157ce0d1344f2a28b40360728a5 EMF+ tdf#142941 Fixes SrcRect implementation in DrawImage record It will be available in 7.3.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.
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/5ee7cb39238a420f1b2ffc83d5b2dc79e0ee3875 EMF+ tdf#142941 Fixes SrcRect implementation in DrawImage record It will be available in 7.2.0.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.
After fixes the EmfPlusRecordTypeDrawImage record with Bitmap embedded, is displaying fine. The EmfPlusRecordTypeDrawImage record with EMF MetaFile embedded is not displaying correctly. The scale and width/heigh ratio is wrong. Here is the place where is the EmfPlusRecordTypeDrawImage implementation: https://github.com/LibreOffice/core/blob/libreoffice-7-2/drawinglayer/source/tools/emfphelperdata.cxx#L1432 It seems that the EMF MetaFile was not displayed correctly due to an issue in GDIMetaFile creation: GDIMetaFile aGDI(image.graphic.GetGDIMetaFile()); Source code: https://github.com/LibreOffice/core/blob/libreoffice-7-2/drawinglayer/source/tools/emfphelperdata.cxx#L1559-L1566 The ratio (eg. where square becomes rectangle) could be corrected with: aSize = image.graphic.GetGDIMetaFile().GetPrefSize(); double ratio = double(aSize.Width()) / double(aSize.Height()); // ratio 0.63 but unfortunately it doesn't fix the scale (the image could be too small or too large). I think the issue should be resolved in during invocation of image.graphic.GetGDIMetaFile() method itself.
Created attachment 174801 [details] Sample EMF+ with embedded EMF, containing green square
Created attachment 174802 [details] Sample EMF+ with embedded EMF, containing green square, exported to PNG with Paint
Dear Valek Filippov, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug