Created attachment 90858 [details] file The attached document does not reproduce the chart graphic as it should. I get one unique color from 2 and the number that should be visible is not displayed at all
The attached document does not reproduce the chart graphic as it should. I get one unique color from 2 and the number that should be visible is not displayed at all
Created attachment 90992 [details] full version of graph not well rendering in libreoffice Here is an extended version of the graphic for the charts seems to be interdependant
If you save this file in libreoffice it will break the charts
Created attachment 90997 [details] illustration
Removed Michael from QA Contact - we don't really use this field and Michael definitely wouldn't be the appropriate person to have on there. This seems to be a new feature coming out (4.1 doesn't show anything useful at all). That being said. I have been able to confirm the issue on: Version: 4.3.0.0.alpha0+Build ID: daa57a101a20e0b37db7090796ad002b8d192b9b Date: Sun Dec 15 23:07:57 2013 +0100 Platform: Ubuntu Linux 13.04 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As I've been able to confirm this problem I am marking as: New (confirmed) Critical - looks like a loss of data for end user - plus new feature, would hate to include it if it's not working right. Highest - new feature, if we're going to advertise this at all, would hope to have it fixed before release of 4.2 Keywords - 4.2mab Whiteboard Status - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage and join us on freenode at #libreoffice-qa There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Changed my mind - major seems more appropriate :-D
Some progress has been made with the latest builds of LO. Both of the 2 colors are now being displayed. However, the number and percent are still not visible.
Created attachment 107365 [details] screenshot in 4.2.6, 4.3.2 and current 4.4master I confirm the behaviour described by Luke in previous comment in 4.2.6.2, 4.3.2.2 and 4.4.0.0.alpha0+ Build ID: 268b9c10c9ff27c74678ace99762f28d58d33012 TinderBox: Win-x86@42, Branch:master, Time: 2014-10-02_23:35:24 see my attached screenshot.
still same issue in 4.4.0 beta1 I move this from mab4.2 to mab4.3 list since 4.2.x is EOL
Created attachment 116157 [details] screenshot in current 5.1 master got worse in 5.1.0.0 alpha+ master (*) see screenshot and compare with previous one (*) Build ID: 6c1cabe677f5eb24b465dd6e316c8c66df64bb29 TinderBox: Win-x86@39, Branch:master, Time: 2015-05-29_06:48:08 Locale: en-US (it_IT)
Tommy, I already filed Bug 91683 for the regression you described.
after that regression has being fixed we are now back to the same situation as in attachment 107365 [details] Both the 2 colors are being displayed but the number and percent are still not visible. retested with LibO 5.1.0.0.alpha1+ Build ID: 4b55c28940d741e53648115a9cfb58f2d6db38a5 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-15_06:14:50 Locale: it-IT (it_IT)
Migrating Whiteboard tags to Keywords: (filter:docx)
I have taken your bug to learn something about the drawingml from libreoffice. What I found is the following: - In the chart1.xml is the <c:showPercent> to "1" set - In chart1.xml is a reference (chart1.xml.rels) to the drawing1.xml. This File has the percent value of the chart. This percent value is in a usershape. - The parsing of the chart gives the following error: warn:legacy.osl:15270:1:oox/source/drawingml/chart/objectformatter.cxx:1100: ObjectFormatter::convertNumberFormat - cannot create number format '' warn:chart2.tools:15270:1:chart2/source/tools/WrappedPropertySet.cxx:152: found no inner property set to map to warn:chart2.tools:15270:1:chart2/source/tools/WrappedPropertySet.cxx:152: found no inner property set to map to warn:chart2.tools:15270:1:chart2/source/tools/WrappedPropertySet.cxx:152: found no inner property set to map to warn:chart2:15270:1:chart2/source/tools/LifeTime.cxx:120: This component is already disposed warn:legacy.osl:15270:1:chart2/source/model/main/DataPoint.cxx:176: data point needs a parent property set to provide values correctly warn:legacy.osl:15270:1:chart2/source/model/main/DataPoint.cxx:176: data point needs a parent property set to provide values correctly warn:legacy.osl:15270:1:chart2/source/model/main/DataPoint.cxx:176: data point needs a parent property set to provide values correctly warn:legacy.osl:15270:1:chart2/source/model/main/DataPoint.cxx:176: data point needs a parent property set to provide values correctly warn:legacy.osl:15270:1:svx/source/unodraw/unoshape.cxx:3672: SvxShape::_getSupportedServiceNames: could not determine object type! warn:legacy.osl:15270:1:svx/source/unodraw/unoshape.cxx:3672: SvxShape::_getSupportedServiceNames: could not determine object type! I think axes format is tried to be parsed (because showPercent is set) but none is defined. The Value is in an other drawingml file and only referenced in the chart (<userShapes>). Hope this helps to finde the cause
Created attachment 130905 [details] Calc Correctly Imports Charts with Text Boxes The missing label is actually an embedded Text Box in the Chart Element. Calc correctly imports this kind of chart. This is a Writer only bug. The attached file was made by copying the bug doc from Word to Excel and changing the Text Box's content to make it clear that it's not a data label.
(In reply to tommy27 from comment #8) > Created attachment 107365 [details] > screenshot in 4.2.6, 4.3.2 and current 4.4master > > I confirm the behaviour described by Luke in previous comment in 4.2.6.2, > 4.3.2.2 and 4.4.0.0.alpha0+ reteste with latest 5.4.0 daily build. bug unchanged from previous screenshot.
I tried to find the difference between the calc and writer version but the callgrind trace is to huge to find anything. It's like finding the needle in a haystack. Has somebody a hint for me, where to look? Or is there a parsing tool for MS files without that dumps the parsed file structure?
bug unchanged in LibO Version: 6.0.0.0.alpha0+ Build ID: 7a743b472dadb817eb7a6ed8063cee80ce7412e8 CPU threads: 4; OS: Windows 6.29; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-17_23:50:28 Locale: it-IT (it_IT); Calc: group same look as in the attachment 107365 [details]
Comment on attachment 90858 [details] file http://madcash.top
bug unchanged in LibO 6.2.0.0.alpha0+ (x64) Build ID: 3017396a26f22ea193b4fd74bc485bc31cd547fe CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-09-04_01:08:03 Locale: it-IT (it_IT); Calc: threaded same look as in screenshot depicted in attachment 107365 [details]
*** Bug 113609 has been marked as a duplicate of this bug. ***
Created attachment 155245 [details] How it looks in LibreOffice 6.4 master Percentage is displayed in master Version: 6.4.0.0.alpha1+ Build ID: de4839e66d3d195315729b95cc144cdab96b6e74 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 although not in the center
The percentage became visible after https://cgit.freedesktop.org/libreoffice/core/commit/?id=48480d4f19d2fb92ca4ae0527eec4753cdc439c0 @Balazs Varga, I thought you might be interested in this issue...
(In reply to Xisco Faulí from comment #22) > Created attachment 155245 [details] > How it looks in LibreOffice 6.4 master > > Percentage is displayed in master > > Version: 6.4.0.0.alpha1+ > Build ID: de4839e66d3d195315729b95cc144cdab96b6e74 > 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 > > although not in the center Even that is now invisible in bibisect-win64-6.5, since: https://gerrit.libreoffice.org/plugins/gitiles/core/+/6f62a5c4ee2c1b7654c7fcaa618fb495e0d32f0a%5E%21/#F0
(In reply to NISZ LibreOffice Team from comment #24) > (In reply to Xisco Faulí from comment #22) > > Created attachment 155245 [details] > > How it looks in LibreOffice 6.4 master > > > > Percentage is displayed in master > > > > Version: 6.4.0.0.alpha1+ > > Build ID: de4839e66d3d195315729b95cc144cdab96b6e74 > > 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 > > > > although not in the center > > Even that is now invisible in bibisect-win64-6.5, since: > > https://gerrit.libreoffice.org/plugins/gitiles/core/+/ > 6f62a5c4ee2c1b7654c7fcaa618fb495e0d32f0a%5E%21/#F0 Indeed!, but it shouldn't be invisible... @Tamás Zolnai, I thought you might be interested in this issue, that changed after 6f62a5c4ee2c1b7654c7fcaa618fb495e0d32f0a
With this patch, custom shapes visible again. Let's close it with Resolved Fixed and create another report for the wrong position and size of the embedded custom shapes. Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/71b66b0039819f38c935b4eb5d5951ceaf6e8468 tdf#138307 Chart import: fix lost custom shape text It will be available in 7.2.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.
*** Bug 93641 has been marked as a duplicate of this bug. ***
Verified in: Version: 7.2.0.0.alpha0+ (x64) Build ID: 368c56144aab5794c39d5bc2082d9b3d6d7cebdb CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded Thanks for fixing!
Szymon Kłos committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cf2449aac0141711a7610d67f7c50cd108e12443 tdf#72776 Allow text removal in the shapes It will be available in 7.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.
I pushed an update to the fix as it was blocking content removal from the textbox (it was visible in LibreOfficeKit case)