Bug 75317 - FILEOPEN: OOXML label placement results in strange placement of <c:manualLayout> labels
Summary: FILEOPEN: OOXML label placement results in strange placement of <c:manualLayo...
Status: RESOLVED DUPLICATE of bug 114821
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: OOXML-Chart Chart-Labels 75054
  Show dependency treegraph
 
Reported: 2014-02-21 11:20 UTC by Luke
Modified: 2018-01-30 23:40 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Chart showing issue with data label (11.51 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2014-02-21 11:20 UTC, Luke
Details
Recreated the data labels in Excel 2007 (11.03 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2014-02-21 12:44 UTC, Luke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2014-02-21 11:20:09 UTC
Created attachment 94506 [details]
Chart showing issue with data label

This bug was tested LibreOffice v4.3 running in windows 7. It appears that LibreOffice loses formatting when importing MS .xlsx files with charts. I have attached an example.

Steps to reproduce the bug:
1. Open Demo-Hayden-Management-v2-chart.xlsx document in calc
2. Open Demo-Hayden-Management-v2-chart.xlsx document in Excel 2007/skydrive
3. Compare the documents. 

Note: The first data label of 2nd column (250) is displayed on the bottom of the chart.
Comment 1 Luke 2014-02-21 12:44:17 UTC
Created attachment 94510 [details]
Recreated the data labels in Excel 2007

I believe this chart was original created in Office 2013. To try to narrow down the issue, I redid data label in Excel 2007. This new chart opens correctly in LO Calc. Attached is the updated file. If you unzip it and run a diff of \xl\charts\chart1.xml you’ll see:

</a:schemeClr></a:solidFill></c:spPr><c:dLbls><c:dLbl><c:idx val="0"/><c:layout><c:manualLayout><c:x val="0"/><c:y val="1.1990407673860906E-2"/></c:manualLayout></c:layout><c:showVal val="1"/><c:extLst><c:ext uri="{CE6537A1-D6FC-4f65-9D91-7224C49458BB}" xmlns:c15="http://schemas.microsoft.com/office/drawing/2012/chart"><c15:layout/></c:ext></c:extLst></c:dLbl><c:dLbl><c:idx val="3"/><c:layout>

Are some new OOXML codes confusing the importer? Can any OOXML gurus shed some light on this issue?
Comment 2 Jorendc 2014-04-27 12:25:48 UTC
Reproducible tested Windows 8.1 Version: 4.3.0.0.alpha1+
Build ID: 145f2e970f46a3a3e5456b122d71f17c3abe878f
TinderBox: Win-x86@42, Branch:master, Time: 2014-04-26_23:32:36

Kind regards,
Joren
Comment 3 Markus Mohrhard 2015-05-11 04:28:18 UTC
This has nothing to do with OOXML at all.

This is part of our manual label placement. So this requires reworking the automatic label placement code. You can get the same problem with a freshly generated document.

I'm not going to look into this any deeper as these placement codes are just a huge pain.
Comment 4 Luke 2016-05-12 02:26:30 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2017-05-22 13:39:58 UTC Comment hidden (obsolete)
Comment 6 Luke 2017-05-24 02:57:49 UTC
Still an issue with:
Version: 5.5.0.0.alpha0+ (x64)
Build ID: 20d04d6938a104124ac06271f17978a290cccf6c
Comment 7 Luke 2018-01-30 22:19:41 UTC
Verified FIXED in Version: 6.1.0.0.alpha0+
Build ID: 20e5f64215853bdd32c5f16394ba7f2f36745904

Thanks Szymon Kłos

*** This bug has been marked as a duplicate of bug 114821 ***