Re: Problems with lighting of extruded custom-shapes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

(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@xxxxxxxxxxx> 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?

Yes.

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
<https://wiki.documentfoundation.org/Development/Budget2022#3D_rotation_of_Impress_shapes>.


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
doc-Format.

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 up in 859 SAL_INFO("writerfilter", "TODO handle shape property '" << rProperty.first << "':'"
860 << rProperty.second << "'");
in writerfilter/source/rtftok/rtfsdrimport.cxx

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.

Kind regards,
Regina




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux