Created attachment 177060 [details] file to reproduce the problem Open attached file. It has a graphic style "myBitmapFill" defined, which sets a bitmap as fill. The style is applied to the two shapes. The shape in normal mode shows the fill, the shape in extruded mode does not show the fill. I see the error in Version: 6.4.5.0.0+ (x64) Build ID: 70a2071ce91b71326659e645dd97996262ea309a CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: threaded It was OK in Version: 5.4.7.2 (x64) Build ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: de-DE (en_US); Calc: CL
How do you apply "extruded mode"? Do you mean "right click then convert To 3D" ? If that is the case, I do not reproduce with Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: c63b86501828d35c3a80aa5be2d70f992b4f1b23 CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Ubuntu_20.04_x86-64 Calc: threaded Best regards. JBF
I mean the icon 'Toggle Extrusion'. In Impress it is in the 'Drawing' toolbar.
(In reply to Regina Henschel from comment #2) > I mean the icon 'Toggle Extrusion'. In Impress it is in the 'Drawing' > toolbar. Ah, OK, so I can confirm the problem. Set as NEW. Best regards. JBF
I have narrowed the interval, when the regression was introduced: OK in Version: 6.1.0.0.alpha0+ (x64) Build ID: d39a8e791618a40328c0f90bece3cc246dcf57f7 CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-06_00:59:07 Locale: de-DE (en_US); Calc: CL Broken in Version: 6.1.0.0.alpha0+ (x64) Build ID: 55b9706bea5aa9b654ab39bc7d56339422e17087 CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-18_06:02:46 Locale: en-US (en_US); Calc: CL
Bibisect result: c413eba35cfe9076054dfde2b3c0d895183039b8 is the first bad commit commit c413eba35cfe9076054dfde2b3c0d895183039b8 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Apr 7 00:54:40 2018 -0700 source dfefe448c41921f2f1e54d3f69b8b9e89031d055 I would like add "Armin.Le.Grand@cib.de" to CC, but he is not in the list...
He has different mail. I added Armin.Le.Grand to the CC list.
clickable link: https://cgit.freedesktop.org/libreoffice/core/commit/?id=dfefe448c41921f2f1e54d3f69b8b9e89031d055
Thanks Gabor for the clickable change! 1st look: Happens as described. When alternatively converting to 3D (using our general 3D engine) works flawlessly - sigh. That means no problem with the 3D engine, but something with the created geometry for the extrude shape. That was once done by Sven, I do not know much about it. My mentioned change is a huge one and contains general improvements, so does not really give a hint here...
Second note: It works when creating a new shape, setting the fill to that bitmap and extruding it -> definitely a problem with the Style involved... AFAIR Sven created helper-SdrObjects for the content (not Primitives - were not available at that time - sigh). A possible reason is that he copied the attributes doing this, but not the styles...(?) Also possible that my huge change removed copying the Style in that case...
Debugging deep into EnhancedCustomShapeEngine::render(), not sure if/how that might have worked earlier. Fact is that the SdrObject holding the CustomShape has the correct ItemSet/StyleSheet, but the object creatd by EnhancedCustomShape2d::CreateObject seems to have the default settings (fillStyle solid, blue). Since that seems to be a hard attribute it does not even help to set the style there (?)
There are multiple objects created for 3D - there is the CustomShape, that creates (A) SdrObject(s) for it's representation (hidden), these are the base to create the (B) 3D Scene (a 2d object) and it's contents (3D SdrObjects). All of these need to have the correct ItemSets/StyleSheets set. All but the 1st are *hidden* but used in visualization and get rendered, so the ItemSet/StyleSheet set there is/will be used. It looks like already in (A) a FillStyle solid is set as hard attribute -> the style from the StyleSheet will not be used. Looking why this happens... Note: I tried to check to have evtl. a version without/before the big change that is marked to have changed this, but not even my 'old' 6.3.6 is old enough - after looking at the code i would really like to see that working in an older version...
Getting forward, in EnhancedCustomShape3d::Create3DObject three 3D objects get created when bUseTwoFillStyles is true. No one tries to get the attributes from the StyleSheet working here, all three objects get attributes set hard as needed - okay, since these are temporary helper objects. 1st 3d obj is the 'front', 2nd is the extrude with the extrude-color set and color fill, 3rd is the 'back' which gets positioned at extrude distance. The 3rd one gets the fill set as bitmap, and indeed, if you *rotate* the shape using 'tilt left' until you see the back of the object, you see the expected bitmap (!) Thus mssing is setting the attributes to bitmap fill at the 'front' shape as it seems, including evtl. missing stuff to make it visible concerning the normal orientations (?). I highly doubt that this was caused by the mentioned change.
Found the problem now: The default FillBitmap gets set at the 3D shape at the 3rd 3D object (back - but it's actually the front). Basic problem is that the source BM gets fetched by using p3DObj->GetMergedItem(XATTR_FILLBITMAP) where at the p3DObj the ItemSet is already set using p3DObj->SetMergedItemSet( aLocalSet ); *but* setting it at the SdrObject removes the StyleSheet's ItemSet which is set as parent in aLocalSet. I found three locations where this is done. Now I have to think about how to best fix that...
Tried diverse methods to fix it, decided for one, see comments in patch. Fix is at https://gerrit.libreoffice.org/c/core/+/141886
Oops, made a small error with the fix, good that we have unit tests - correcting. Note: my testbuild with the version before that big change is done, and indeed does not happen there, so bibisect is reliable :-) I have no clue why not, the code I just worked on is basically the same (?)
Fix is at https://gerrit.libreoffice.org/c/core/+/141886
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/885fb902ce7765f04c98cebedf96959007cef05b tdf#146360 use correct data source to access object properties It will be available in 7.5.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.