Bug 138036 - FILEOPEN DOCX Line Chart Legend entry does not fit
Summary: FILEOPEN DOCX Line Chart Legend entry does not fit
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:ooxml
Depends on:
Blocks: OOXML-Chart
  Show dependency treegraph
 
Reported: 2020-11-06 11:32 UTC by NISZ LibreOffice Team
Modified: 2024-11-11 03:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word (19.37 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-11-06 11:32 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer (70.84 KB, image/png)
2020-11-06 11:32 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-11-06 11:32:01 UTC
Created attachment 167057 [details]
Example file from Word

Attached user made file contains a simple line chart with legend.
When opened in Writer the lengend only has one entry visible, since the other does not fit inside. Manually resizing the legend makes the other entry visible too.

Steps to reproduce:
    1. Open attached file

Actual results:
Only the first data series legend entry is visible.

Expected results:
Both entries should be visible.

LibreOffice details:
Version: 7.1.0.0.alpha1+ (x64)
Build ID: eeed9103350d886f5913aed9b525d863a421dffa
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

Also in:
Version: 6.0.0.3
Build ID: 64a0f66915f38c6217de274f0aa8e15618924765
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: en-US (hu_HU); Calc: CL

Version: 5.2.0.4
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; 
Locale: en-US (hu_HU)

Not yet in:
Version: 5.1.0.3
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
Locale: en-US (hu_HU)
Comment 1 NISZ LibreOffice Team 2020-11-06 11:32:18 UTC
Created attachment 167058 [details]
Screenshot of the original document side by side in Word and Writer
Comment 2 Aron Budea 2020-11-08 03:09:42 UTC
(In reply to NISZ LibreOffice Team from comment #0)
> Not yet in:
> Version: 5.1.0.3
> Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
> CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
> Locale: en-US (hu_HU)

There's a bit of discrepancy between this and the version field (4.1.0.4). My experience is that the chart is only imported since version 4.2.0.4, and at this point both legend entries are visible, but are at the center of the chart. In 5.0.0.5 the legend is moved to the top, and only one is visible.

The change occurred with the following commit, bibisected using repo bibisect-50max:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=8eb880a04d17c888c2c986426e935e02ae309e7a
author		Stephan Bergmann <sbergman@redhat.com>	2015-01-08 11:55:20 +0100
committer	Stephan Bergmann <sbergman@redhat.com>	2015-01-08 12:04:15 +0100

HACK to avoid empty page size/div by 0 in chart2 LegendWrapper::setPosition
Comment 3 NISZ LibreOffice Team 2020-11-09 16:52:59 UTC
Looking at it once more it seems like this happens since 5.1, and in 5.0 these fitted well:

Version: 5.0.0.5
Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Locale: hu-HU (hu_HU)

Also bibisected with bibisect-win32-5.0 to the same commit. Before the width of the legend was too huge, also worth noting: it has a custom size set in Word.

However looking at the image I think the real problem might be that the legend keys are visibly longer in LO than in MSO so they need a bit more space too, but the custom size of the legend is a hard limit on that.
Comment 4 QA Administrators 2022-11-10 04:03:14 UTC Comment hidden (obsolete)
Comment 5 QA Administrators 2024-11-11 03:13:06 UTC
Dear NISZ LibreOffice Team,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug