oox import/export of custom shape extrusion
rb.henschel at t-online.de
Fri Mar 19 15:30:31 UTC 2021
Miklos Vajna schrieb am 19.03.2021 um 14:36:
> Hi Regina,
> On Fri, Mar 19, 2021 at 02:20:54PM +0100, Regina Henschel <rb.henschel at t-online.de> wrote:
>> It would indeed make the structure much easier, if only the situations "no
>> grabBag" and "only grabBag" need to be handled. So that is fine for me.
>> OOX has some 3D properties, which do not exist in ODF and/or cannot be
>> rendered by LO. Those would be lost in a PPTX - LO - PPTX roundtrip. Of
>> cause they will be lost in PPTX - LO - ODF anyway.
> The grab-bag format is only in the memory, so you don't have to care
> about stability / compatibility there (just keep import and export in
> sync). If something works for LO shapes, those can be properly
If the shape is edited, the grab-bag can be emptied.
I thought to only put something into the grab-bag on import, if LO
cannot handle it and it is needed in export. So removing something from
the grab-bag should not be necessary. That means import has to be done
parallel to export.
Removing something in the grab-bag when shape is edited, would require
changes in places, which are not related to import/export. I think, that
will be complicate and dangerous.
> And finally if a property is not something an LO shape / ODF can handle,
> it can stay in grab-bag.
Exactly that is what I have called "merge". The export happens in
It means, that I have to put those values, which are set by LO and
therefore not in the grab-bag, into the sequences aEffectProps,
aLightRigProps and aShape3DProps there.
> That way you would never have conflicting information in the grab-bag
> and in the real document model on export. Would this approach work?
If I not only implement export but handle import at the same time it
should work. I think, I will start and sometime in April you can see
some concrete code in Gerrit.
Thank you for your thoughts so far.
More information about the LibreOffice