Issue 60470

Summary: 3D-Pie Chart broken after save as .sdc and reload
Product: General Reporter: kla <thomas.klarhoefer>
Component: chartAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, tony.galmiche.ooo
Version: 3.3.0 or older (OOo)   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description kla 2006-01-13 07:23:50 UTC
Create an 3D-Pie Chart and save as .sdc file.
reopen -> Chart is broken
Comment 1 bjoern.milcke 2006-01-16 09:54:14 UTC
Changed target to 2.0.3
Comment 2 bjoern.milcke 2006-01-31 14:48:03 UTC
Here is what I found out:

1. Loading binary 3d charts works
2. Saving 3d binary charts with recent version (SRC680.m149) creates a corrupt file.
3. On Reload there is an Assertion about "Wrong Item Type in Set" while loading
the chart's item pool. This concerns an SdrOutlinerSetItem.
4. When the 3d Scene is loaded, the light sources seem to be corrupt. There is
an error message about "too many bytes read". Maybe this is a consequence of 3.,
but before the corrupt lights are read, e.g. the 3d matrix is loaded as unity
matrix which looks good to me.

->AW: As the SdrOutlinerSetItem was obviously removed with a BFS01 comment in
the non-binfilter code, I assume you know more about this item than me. But
probably this is an issue of saing the drawing layer (which is done for charts,
but only important on reload for 3d charts).
Please have a look.
Comment 3 Armin Le Grand 2006-05-16 16:02:24 UTC
AW: Changing target
Comment 4 Armin Le Grand 2006-07-04 11:48:35 UTC
Moved target.
Comment 5 Armin Le Grand 2007-06-22 12:10:27 UTC
AW->BM: I guess this does no longer hapen with chart2 ?
Comment 6 bjoern.milcke 2007-06-22 12:19:41 UTC
No, the bug still occurs. The problem is in binfilter, where we didn't change
anything. There is still an assertion message: "Error: CheckRecordIntegrity
(ID=DrOb) (3 von 3 Records gelesen):
- 1649373764 Bytes zuviel gelesen.
- Aktuelle Fileposition liegt nicht am Ende eines SubRecords."
Comment 7 Armin Le Grand 2007-12-17 09:44:49 UTC
AW: Moving target
Comment 8 Marcus 2017-05-20 11:27:33 UTC
Reset assigne to the default "issues@openoffice.apache.org".