Description: I am trying to place certain images into a Writer document. Other images work fine, but with these ones I just get a black box with the image's aspect ratio. It is possible to make the image display normally using the Brightness control, but the default is black. Sample image: http://www.ramendik.ru/pic-5-1as.bmp These are BMP files made by an obscure conversion utility. They open fine in chrome and gwenview and gimp. Moreover. if I use imagemagick or gimp to convert to tiff or png, the problem persists! After a conversion to JPG the images do display but JPG affects the quality. A Gimp conversion to PSD also fixes the issue, but not an ImageMagick conversion to PSD. This happened in version 5.3.5.2 on OpenSuSe Leap for me. Others in the ASk question at https://ask.libreoffice.org/en/question/137078/putting-certain-images-into-writer-results-in-image-sized-black-box/ were able to reproduce on Linux but not on Windows. EDIT. from Help > About: Version: 5.3.5.2 Build ID: 30m0(Build:2) CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; VCL: kde4; Layout Engine: new; Locale: en-IE (en_IE.UTF-8); Calc: group The system is Linux, namely OpenSUSE Leap 42.2. I start Writer, click the icon to create a blank new file, go to Insert>Image..., and select this image. I see the image as a black rectangle. Resulting ODT file: http://www.ramendik.ru/blankimage.odt Steps to Reproduce: 1. Create a Writer document 2. Download the sample file http://www.ramendik.ru/pic-5-1as.bmp 3. Use the Insert > Image menu command to insert the image into the document Actual Results: Black rectangle with aspect ration of the image is displayed Expected Results: Image is displayed Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 5.3.5.2 Build ID: 30m0(Build:2) CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; VCL: kde4; Layout Engine: new; Locale: en-IE (en_IE.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Created attachment 137733 [details] The bitmap from description Reproducible with Version: 5.4.2.2 Build ID: 1:5.4.2~rc2-0ubuntu0.16.04.1~lo2 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group But not with Version: 5.4.2.2 (x64) Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Windows 6.19; UI render: GL; Locale: ru-RU (ru_RU); Calc: CL
Might be fixed in 5.4.4 or higher (see bug 113875). Please retest.
(In reply to Telesto from comment #2) > Might be fixed in 5.4.4 or higher (see bug 113875). Please retest. Nope, still black. Works in 3.6, though. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: d4c0e7ef2b7f7e3cb36996bad72ac255b630beb4 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 8th 2018 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
Reproduced in Version: 6.1.0.0.alpha0+ Build ID: 3ea82be2ca7e1d65c718097ccc674ae98ecd98c5 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not in Version: 6.1.0.0.alpha0+ Build ID: 3ea82be2ca7e1d65c718097ccc674ae98ecd98c5 CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: author Armin Le Grand <alg@apache.org> 2013-10-31 14:43:21 +0000 committer Caolán McNamara <caolanm@redhat.com> 2013-11-05 15:24:18 +0000 commit 2e5167528f7566dd9b000e50fc1610b7bf99132a (patch) tree d3e8438457c0bb1b85ac80b2fbd485f1959d744c parent 57c54792781cc9befe3a65a97b37fa85f89da0ae (diff) Resolves: #i123500# unified Graphic processing to use GraphicPrimitive2D (cherry picked from commit f5d69b2b8b002ca6905496a9d9065ef76b5641d7) Bisected with: bibisect-42max Adding Cc: to Armin Le Grand
Still reproducible in Version: 7.0.0.0.alpha0+ Build ID: 5a94ac9eec4a63708262b2389aa2a434aa47112e 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 @Armin, I thought you might be interested in this issue after you fixed bug 89901
*** Bug 130774 has been marked as a duplicate of this bug. ***
Cannot rep under Win, neither GDIPlus nor OpenGL nor Skia. Maybe *very* specific to some graphic backend...?
(In reply to Armin Le Grand from comment #8) > Cannot rep under Win, neither GDIPlus nor OpenGL nor Skia. > Maybe *very* specific to some graphic backend...? it seems it can only be reproducible in gen under linux. it works fine for me in Versión: 6.4.2.2 (x86) Id. de compilación: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 Subprocs. CPU: 2; SO: Windows 6.1 Service Pack 1 Build 7601; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
Linux: - not under: gtk3 - happens: x11 Does someone know how to create others, e.g. VCL: gtk2/VCL: kde4...? And how to enable OpenGL as mentioned - cannot find that (anymore?) in my linux version..? @Xisco: Only could repro using x11 by setting 'SAL_USE_VCLPLUGIN=gen', does not happen using gtk3...?
(In reply to Armin Le Grand from comment #10) > Linux: > - not under: gtk3 > - happens: x11 > Does someone know how to create others, e.g. VCL: gtk2/VCL: kde4...? And how > to enable OpenGL as mentioned - cannot find that (anymore?) in my linux > version..? > > @Xisco: Only could repro using x11 by setting 'SAL_USE_VCLPLUGIN=gen', does > not happen using gtk3...? You can try with kf5 which is short for KDE Frameworks 5. Gtk2 was already removed. Tools - Options - LibreOffice - View - Use OpenGL for all rendering
@Michael, this issue is only happening with gen, could you please give it a try with kf5 ?
(In reply to Xisco Faulí from comment #12) > @Michael, this issue is only happening with gen, could you please give it a > try with kf5 ? I cannot reproduce with Version: 7.0.0.0.alpha0+ Build ID: aa24771563425072c710e8c426323ed311437f13 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-US (en_GB.UTF-8); UI-Language: en-US Calc: threaded but can when using the gen VCL plugin instead Version: 7.0.0.0.alpha0+ Build ID: aa24771563425072c710e8c426323ed311437f13 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: x11; Locale: en-US (en_GB.UTF-8); UI-Language: en-US Calc: threaded -> kf5 seems to be unaffected.
OOps- getting an exception when debugging paint of that Bitmap - in OutputDevice::DrawBitmap rBitmap.GetSizePixel() throws due to having a mxSalBmp member with a ptr, but looks bad... Thought it's something in rendering - X11/XImage stuff, but seems to have to do with loading and X11 impl DDB/DIB stuff...
Debugged deeply into stuff I do not really know - it's all about X11SalBitmap. Good method to debug is: - new draw - insert image - break at X11SalGraphicsImpl::drawBitmap in vcl/unx/generic/gdi/gdiimpl.cxx - move the image or +/- for zoom in/out When changing the created colors in line 571 in aNewVal (one green one black what is correct) -> all get s painted green. That hints that the BM does only contain zeros, no pixels set. Didi I mention: BM is a DIB bitmap 1bit depth, 2 colors, read from ReadDIBBitmapEx in vcl/source/gdi/dibtools.cxx - all that has no flaws (else would be wrong on other systems too) Also interesting: OutputDevice::DrawBitmap calls OutputDevice::ScaleBitmap in line 165 in vcl/source/outdev/bitmap.cxx - that method *only* does scale when BM gets smaller - NO scale when growing - strange, who would've thought that for a method with that name...? Anyways, debugged that one doe to it was being used and did something in a situation where it was getting smaller for screen paint - was wondering why it was later scaled AGAIN in X11SalBitmap::ImplDraw/ImplSalDDB::ImplDraw again (?) but I had zoomed now to a bigger BM - sigh. Anyway - it seems as if one of these zooms (or both) somehow force all pixels to zero -> only black is used for paint. Or ImplSalDDB::ImplDraw and XCopyPlane does not work. Note: There are quite some extra treatments in vcl/unx/generic/gdi/salbmp.cxx for '1 == GetBitCount()' - also in vcl/unx/generic/gdi/salbmp.cxx which may be related - e.g. ( 1 == nDepth ) ? XYBitmap :ZPixmap is used which seems to directy use different mechanisms for x11 - which I do not know about... @Xisco: If you know someone who knows x11 better at that stage, feel free to note that person - I'm not sure I can do much without investing lots of time...
@Caolán, any opinion wrt comment 15 from Armin ?
no idea off the top of my head, but removing the x11 drawing in favour of reusing same cairo based one that gtk3 and kf5 uses would be a good step IMO
Dear Armin Le Grand, 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.
repro 7.2+ when inserting the image from comment 1 into a new document. SAL_USE_VCLPLUGIN=gen instdir/program/soffice confirmed that it still works fine with VCL gtk3.
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
Dear Mikhail Ramendik, 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