Problems with lighting of extruded custom-shapes
rb.henschel at t-online.de
Fri Jan 7 18:22:19 UTC 2022
(Hi Miklos, I repeat here my answer to you for the list, because CC
didn't work because the attachment was too large.)
Miklos Vajna schrieb am 07.01.2022 um 14:30:
> Hi Regina,
> On Thu, Jan 06, 2022 at 10:33:54PM +0100, Regina Henschel <rb.henschel at t-online.de> wrote:
>> If the OOXML 'scene3d' and 'sp3d' elements will be imported so, that
>> extruded custom-shapes are used, the decisions here will influence that
>> implementation too.
> Is it correct that these are not taken into account while rendering at
> the moment?
An extruded shape is imported without extrusion, a "3D Model" is shown
with its fallback image, an extruded text (new kind of WordArt) is not
even imported as Fontwork shape but as text box.
> I assume doing that would be the scope of
Yes, but the Budget2022 proposal has import of text in addition, which
can be included in the object rotation in MSO.
However, the suggestion text is not clear. It can be interpreted as
using "SdrObjCustomShape" or as using "E3dScene".
> But if that's true, then we don't really map LibreOffice's 3D objects to
> MSO formats in general, am I right?
The "E3dScene" has no corresponding shape type in OOXML and not in
binary MS format. So those objects are totally lost in export to OOXML
and replaced with image in export to binary MS format.
MS goes a different way and has introduced "3D Model". That is a GLB
media file, which is inserted as w:graphic and uses the object rotation
and camera from OOXML.
An extruded "SdrObjCustomShape" both as shape and as Fontwork is
exported to OOXML without extrusion.
Exchange in RTF doesn't work too.
Only exchange as binary MS format works beside the shortcomings on which
I currently work.
So exchange of any kind of 3D object with MS Office is in a very bad state.
>> Fontwork is affected too, because it is only a special mode of a
>> custom-shape >
> So would that mean fontwork is the only case where we currently import a
> shape from MSO formats and that results in a 3D object on our side?
No, Fontwork/Wordart in 3D mode doesn't work too. Same as with shapes,
only binary MS format works.
> I hope once these are clear, we can discuss the individual properties
> more easily. :-)
>> In case you want to test these MSO properties in a current MSO, then use a
>> text document and save it to RTF. MSO provides then a UI for extruding
>> shapes which uses these attributes known from the binary format, and you can
>> edit the resulting RTF-file instead of working in binary format. LO cannot
>> import the shapes in the RTF-file directly. Instead let MSO save it to
> Somewhat related, if you have some RTF document where these properties
> are not imported, but the DOC version of it is imported correctly, I
> would be interested to look at that -- could you please file a bug and
> CC me?
No extrusion properties are imported from an RTF document. They all end
859 SAL_INFO("writerfilter", "TODO handle shape property '"
<< rProperty.first << "':'"
860 << rProperty.second << "'");
I'll write a bug report for RTF import.
The import of the DOC version works in principle, but has wrong units
for "Shininess" and for "Specularity" and needs to explicitly set
default values if they are different from ODF defaults. I'll fix that
together with the rendering problems.
More information about the LibreOffice