Issue 123542 - In 3dScene the attributes dr3d:min-edge and dr3d:max-edge of a dr3d:cube are lost
Summary: In 3dScene the attributes dr3d:min-edge and dr3d:max-edge of a dr3d:cube are ...
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: save-export (show other issues)
Version: 4.1.0-dev
Hardware: All All
: P3 Normal (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords:
: 123561 (view as issue list)
Depends on:
Blocks:
 
Reported: 2013-10-24 09:07 UTC by Regina Henschel
Modified: 2017-05-20 10:34 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Example file with dr3d:min-edge and dr3d:max-edge (12.94 KB, application/vnd.oasis.opendocument.graphics)
2013-10-24 09:07 UTC, Regina Henschel 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2013-10-24 09:07:06 UTC 
Created attachment 81816 [details]
Example file with dr3d:min-edge and dr3d:max-edge

Open the attached document. It has a 10cm x 10cm x 10cm extrusion object without fill. Therein is a dr3d:cube with dr3d:min-edge="(1000 1000 1000)" and dr3:max-edge="(9000 7000 5000)". You see the dr3d:cube object as solid cuboid in the size which respond to the min-edge and max-edge attributes.

Save the document as new document and reopen it. Notice, that the dr3d:cube is reset to the default cube.

Expected behavior: The dr3d:min-edge and dr3d:max-edge attributes are preserved, even if there exists no UI for them.

Less good, but acceptable as intermediate solution, convert the attributes to a transformation matrix on import.
Comment 1 Armin Le Grand 2013-10-30 11:47:31 UTC 
ALG: In the new saved file the entries for dr3d:min-edge and dr3d:max-edge in dr3d:cube are simply missing. Same for dr3d:transform for the dr3d:extrude object. I remember that there was something in ODF export to not write that stuff when it's equal to the default values; need to check the exporter...
Comment 2 Armin Le Grand 2013-10-30 12:09:57 UTC 
ALG: Cube is written in XMLShapeExport::ImpExport3DShape, and all the values are passed as needed, no ignore due to defaults or similar. It looks as if the values created are simply not written...
Comment 3 Armin Le Grand 2013-10-30 13:02:36 UTC 
ALG: Already happens in 401, 400, 341, 330, 320 and 220, seems a rather old problem...
Comment 4 Armin Le Grand 2013-10-30 13:26:17 UTC 
ALG: @Regina: You are looking for defaults; some are comared in the exporters (e.g. XMLShapeExport::ImpExport3DShape, see 'if(aPos3D != ::basegfx::B3DVector(-2500.0, -2500.0, -2500.0)) // write only when not default'), please look for similar stuff in xmloff project.
Comment 5 Armin Le Grand 2013-10-30 13:54:16 UTC 
ALG: I found that the SvXMLElementExport constructor always clears the AttrList on the exporter, but this would mean that the object size of sphere and cube were never exported at all;
@Regina: How did you create that file? Is it a result of saving in AOO or hand-crafted?
Comment 6 Regina Henschel 2013-10-30 14:20:24 UTC 
It is "hand-crafted", following the ODF spec. A sphere example is in bug 123561.

I had tried "hand-crafted" transformation matrices too. I have found no problems with transformation matrices, only the direct attributes are missing.

(Thanks for the hint to xmloff, it confirms my observations.)
Comment 7 Armin Le Grand 2013-10-30 14:30:26 UTC 
ALG: Thanks Regina, this makes me believe that for cube and sphere this never worked at all; I just did not want to believe this, but it's true. It works as follows:

(a) AddAttribute is used to collect any attributes at the export instance
(b) SvXMLElementExport constructor consumes all these, resets the list to null
(c) SvXMLElementExport destructor closes the scope

This is not very object oriented (that would require that attributes are collected at the instance of the opened scope AKA SvXMLElementExport) and leads to dangerous situations:

- All attributes have to be added before the scope is created using SvXMLElementExport
- Attributes added after this are lost
- new scopes should only be created between (b) and (c); creating one between (a) and (b) will add the attributes to the wrong scope.
This is especially dangerous with calling sub-routines in-between (a) (b) and (c) without knowing if in there evtl. new scopes get opened and thus is a mine field. Guess what: No line of documentation at the involved classes...

The result is that XMLShapeExport::ImpExport3DShape for cases XmlShapeTypeDraw3DCubeObject and XmlShapeTypeDraw3DSphereObject create attributes for position and size, but these never get written because they get added after the scope is created using SvXMLElementExport. This only was never detected since users usually do not resize cubes and spheres, but only modify the 3D scene this shapes reside in. Argh!

Okay, but the fix should be easy...
Comment 8 Armin Le Grand 2013-10-30 14:39:45 UTC 
ALG: Corrected cases XmlShapeTypeDraw3DCubeObject and XmlShapeTypeDraw3DSphereObject in XMLShapeExport::ImpExport3DShape to create the new scope after adding the attributes, not before that. Reload works as expected. Preparing commit...
Comment 9 SVN Robot 2013-10-30 14:45:09 UTC 
"alg" committed SVN revision 1537113 into trunk:
i123542 corrected ODF XML export of 3D cube and sphere
Comment 10 Armin Le Grand 2013-10-30 14:45:46 UTC 
ALG: Checked other cases, seemed to have been the only ones. Comitted, done.
Comment 11 Armin Le Grand 2013-10-30 15:55:57 UTC 
*** Issue 123561 has been marked as a duplicate of this issue. ***