Description: We are not drawing images that are embedded in EMF+ brushes. See for example the testbed EMF+ file from the libUEMF project - halfway down there are a row of rectangles that contain images. None of these display the images in Libreoffice. Steps to Reproduce: Open the file test_libuemf_p_ref.emf in LibreOffice Actual Results: The middle row of images show in a solid colour. Expected Results: The solid colors should actually show patterned images. Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 156509 [details] test_libuemf_p_ref.emf test image from the libUEMF project
Created attachment 156510 [details] How test_libuemf_p_ref.emf should display
Created attachment 156511 [details] How test_libuemf_p_ref.emf displays
I've currently got a number of patches queued up in gerrit around EMF+. The first thing we need to do before we can implement drawing the images is to actually read in the image. I have pushed the following gerrit patch: https://gerrit.libreoffice.org/#/c/85054/ This needs to be reviewed. From here we can figure out what needs to paint the images in the brushes.
Whilst I am reading in EMFPImage objects with the below fix, there is a larger issue at hand. We are currently not reading in uncompressed bitmap data in EMFPImage::Read() The code currently reads that if the bitmap type is 0x0 then it considers this to be a "non native format", when in fact the spec for EMFPlusBitmap relies on the enumeration in "2.1.1.2 BitmapDataType Enumeration". There are two types of bitmap - one that is compressed, the other that is not compressed (0x0). If we hit uncompressed data, then we need to read in an EmfPlusBitmapData object, specified in "2.2.2.3 EmfPlusBitmapData Object" of [MS-EMFPLUS].
So here is where I am up to. My first task was to find the code that reads in the EMFPImage. This was difficult because you can’t pass an SvMemoeyStream to a SvStream. after puzzling this out, I realised you read in a byte stream the size of the record from SvStream and then construct the SvMemoeyStream from this. Then I checked the bitmap I read, and I realised it wasn’t reading in anything... so I checked the function that reads in the bitmap data. That’s when I realised we read compressed bitmaps, but not uncompressed DIBs. Fine. But how to read the data? We have ReadDIB functions, so I tried to read in the raw data and ignore the v5 header. This will simply not fly with the current VCL functionality. To get this working I have had to check if palette entries are being used, setup a manual v5 DIB and I then inject this into the DIB read function. So far so good. But then I found we don’t handle the 16bpp scanline formats. These esoteric formats were removed some time ago, and in fact two of the formats (the RGB565 ARGB1555 formats) weren’t implemented anyway. So I had to implement a conversion for these scanline formats into either 24 or 32 bpp scanline formats. So the current state is... I have read in the graphic now, but for some reason i now can actually draw the bitmap. I shall persevere!
Created attachment 156760 [details] EMF+ file with textured brush This is minimal EMF+ file with textured brush usage. It could be used for testing purposes. @Chris Please let me know if you will need something special
Created attachment 156761 [details] EMF+ file with textured brush exported by Paint
Created attachment 156762 [details] EMF+ Tile images
Created attachment 156764 [details] EMF+ Textured ellipse
If you will needs some specific example image just let me know. A lot of examples to generate EMF+ image, could be found there: https://docs.microsoft.com/pl-pl/windows/win32/gdiplus/-gdiplus-filling-a-shape-with-an-image-texture-use
Awesome! Thanks, I'll get started on this in the new year :-)
@Bartosz - the tiled one - is that tiled as in tesselated?
My code only processes uncompressed data. This brush is using compressed data.
Oh... the way we are handling multipart objects is the cause of this issue. This is going to require some deep work...
Scratch that last comment. This is getting quite hard to track down.
Dear Chris Sherlock, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.
Dear Chris Sherlock, 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
Bartosz Kosiorek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6c05a6339c27038b14d2f35f8f4b2b94335d6491 tdf#129342 tdf#170985 EMF+ Implement BrushTypeTextureFill for bitmaps It will be available in 26.8.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-26-2": https://git.libreoffice.org/core/commit/71b257e4faf940a300753ba3fb8156271d51f9b0 tdf#129342 tdf#170985 EMF+ Implement BrushTypeTextureFill for bitmaps It will be available in 26.2.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.