Steps: 1. Open attachment 93843 [details] Observed behaviour: Red chart bars are not imported Reproduced in Version: 5.3.0.0.alpha1+ Build ID: 757a60d01dd152aadab2ba3c8224252481ce8a88 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Regression introduced by: author Jean-Tiare Le Bigot <admin@jtlebi.fr> 2016-10-13 21:43:41 (GMT) committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-11-06 06:02:27 (GMT) commit 4bcf1872bbe9db1388769485a7e4c0cbcce3d53c (patch) tree 0110875cf6db25b7208099e9394995254111b221 parent 17e9dc436bc6ad8d3a5bbde15d4d47262650aa2c (diff) chartx: fix sparse chart import Adding CC: to Jean-Tiare Le Bigot
I wonder how this document has been created. It seems to use stranegely exotic features... Basically, there are (internally): 1/ a bar chart 2/ a line chart Both have 13 elements and, interesting fact, there own category column. That makes 4 series of 13 elements. The fun begins when, strangely, the category series of the line chart decides to declare 15 elements ans start at offset 2. To handle this, I guess MSO parses the <c:f>Sheet1!$A$4:$A$16</c:f> like fields and uses it as a base for offset calculation. But that would be a *lot* of non-fun to implement... Anyway, that's the root cause.
Moving to the chart component to make sure it shows up in my regression list.
The mentioned commit is also affecting attachment 85112 [details] as the second chart is no longer displayed after the commit. Raising severity and priority
I h've commited a tentative hack/fix to https://gerrit.libreoffice.org/#/c/30942/. I'm really not proud of it... It should use the formula parser instead of this ugly hack but it's not possible in that function and changing it to accept more parameters would break the API (inheritance...). And it's only available in calc anyway, which is not using this code path either. Moreover, whenever you start to take data into account that you previously ignored (the offset in this specific commit), you start to see some bugs that were previously hidden. For instance, the second graph in the doc you attached loads fine except that... there are now 11 empty leading cells as requested by the file. Word is smart enough to trim that at draw time. I did not find where to do this. I'm out of luck... Trying to do well. Break even more :( I'm definitively not an expert regarding LO code base. Could you point me through ways to improve this ? Especially on how to trim the leading cells ? I'm starting to wonder if we should not revert all this mess...
Don't worry. I'm back from vacation and have a look at the chart regressions.
Hello Jean-Tiare, I've just tested your commit in Version: 5.4.0.0.alpha0+ Build ID: 18b3138a7ac4da823e41640bed8a4707029b8fb0 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and the problems are fixed now. Thank you very much for your work. Close this issue as RESOLVED FIXED whenever you have some time. Regards
Well, my previous comment 7 wasn't totally correct. In Version: 5.4.0.0.alpha0+ Build ID: 7fc84a8e6678e3d0399983f5a078c9b2beb6ee4b CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group the chart bars from attachment 93843 [details] aren't visible yet. However, the problem with regards to attachment 85112 [details] is already fixed, thus, lowering severity and priority
Created attachment 134859 [details] How it looks in MSO 2010
Still reproducible in Version: 6.0.0.0.alpha0+ Build ID: 1e87e93132f808ab95eab932b36bfe40d3cc607a CPU threads: 1; OS: Windows 6.1; UI render: default; TinderBox: Win-x86@39, Branch:master, Time: 2017-07-25_06:09:29 Locale: es-ES (es_ES); Calc: group @Dennis, do you think you could take a look at this one at some point?
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still occurs in 6.2.0.0.alpha1+ (140434a7677946020bb2c6db9ed3afe8998ee7d0) / Windows 7.
Still exists in version Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
Still reproducible in Version: 6.4.0.0.alpha0+ Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Balázs Varga, since you recently fixed bug 124083, which are introduced by the same commit, I thought you might be interested in this issue...
Probably, this patch could help here too: Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e0b0502516a10181bbd1737b93b38b2bba4c98e8 tdf#128016 Chart OOXML Import: fix duplicated category labels It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 155003 [details] How it looks in LO MASTER
Verified in Version: 6.4.0.0.alpha0+ Build ID: 9b5dad13b56bdde7c40970351af3da3a2c3c9350 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Balazs Varga, thanks for fixing this issue. Can it be backported to libreoffice 6.3?
> @Balazs Varga, thanks for fixing this issue. Can it be backported to > libreoffice 6.3? Yes, it would be good. But there will be some merge conflict. My first tip is we need these too: https://cgit.freedesktop.org/libreoffice/core/commit/?id=fa0a981af41a2606541eec1cb20a379a739691e0 and https://cgit.freedesktop.org/libreoffice/core/commit/?id=8906275d40a1828db684e7d9c9bc4934a937bc6c but I will check first. :)