Description: When I set the line width to 0.03 it works correctly for an hour, or for a few exports to png, but over time the export stops working correctly. It looks correct on screen, but does not export correctly. Data series is configured for continuous line, 0.03 inches, 0% transparency. Leave gap. Line width at 0.00 has no problems. Larger width seems to trigger the malformed dots faster. The lines look like they have holes in them, but are actually reversed normals for the circles, when overlapping and alternating in which direction their normal points in, looks like holes in the line. Once the bug starts happening, reopening the document, or even closing and restarting libreoffice does not clear the problem. It is persistant between processes. Only rebooting the operating system will solve it. So something persists in memory that gets corrupted by some kind of memory leak, is what it looks like. I've upgraded my OS this month to 64-bit, it is Debian v.9.13, and I am surprised to find this long-endured bug still there. I know this is not the Newest version possible, but is newest in the repository. After erasing/moving my user profile, the first export was ok. Then I opened a csv, copy the new lines of data, paste special here in .ods, and export png. Broken already and rather quickly. Next I moved out the OO-v3 user so it would really start fresh. The first export without editing the .ods is bad right away. Steps to Reproduce: 1.Make a line chart, range is a few thousand lines long. 2.Export to png 3.Wait an hour, repeat #2 until fails. Honestly I don't know what the trigger is yet, even after years of working around the bug. What is consistent is the line width, if I want a thicker line, I have this happen. I have also edited the line width, export, repeat until it breaks. Actual Results: Here's the example to help identify what is going on. my png when broken: https://www.seahorsecorral.org/images/tests/out-temps-96hr-bad.png The above is 288 data points per day, so just over 1000 lines. another example I have shows partially deformed, and partially correct, 6000 data points: https://www.seahorsecorral.org/images/tests/temps-month_0.03d1.png It started with 6 series, I edited this line to be 0.03 inches, then slowly removed the other series until only this one left. Expected Results: https://www.seahorsecorral.org/images/tests/out-temps-96hr-good.png Be consistent over time. and not be a line full of holes. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 5.2.7.2 Build ID: 1:5.2.7-1+deb9u11 CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; VCL: gtk2; Locale: en-US (en_US.utf8); Calc: group
Please could you attach a document to test and a screencopy of what you see when it fails. Status has been set to NEEDINFO, please set it back to UNCONFIRMED once requested information has been provided. Best regards. JBF
Certainly, here's document #1: https://www.seahorsecorral.org/images/tests/151138-temps-log-a.zip Right click on the smaller chart, export to png. Should look like this: https://www.seahorsecorral.org/images/tests/out-temps-96hr_t1.png Edit the larger chart below the first, if you export to png, it'll probably look fine. For the next image demonstrating the bug without waiting, https://www.seahorsecorral.org/images/tests/temps-month_t2.png I did the following: Right click the larger chart, Edit, Edit range Remove the 3 series: CPU, GPU, and H_44. Ok Select the AIR_OUT , change the line width to 0.04 by clicking the up arrow next to the current width. Also I changed the color to be consistent with the smaller chart, darker and more contrast. Click outside the chart to deselect it, Right click the chart, export to png. Also the export takes 2 minutes to finish. See the bug? See in image t2 how AIR_OUT changes back and forth from solid to reversed normals, or circles with holes. I saved my document at this point to share, https://www.seahorsecorral.org/images/tests/151138-temps-log-c.zip in hopes the contents help you see the bug. If I close it, and reopen it later, the saved image still looks wrong, or buggy. The bug is demonstrated in this document. It won't get updated until you Edit it. Minimize the window for half an hour, come back, add data points to the bottom, export the small chart, check for bug. Repeat every 30-60 minutes, adding 6-12 lines of data to the bottom to track a temp gauge. By 2 hours it should stop exporting correctly. Once you achieve this level to replicate my report, if you close the document, even the Libreoffice program, and reopen it, in my case it will always output bad lines until I reboot completely. While doing this myself to confirm my example file will perform, When I check on memory usage with htop, I see: 26781 sandreas 20 0 1626M 249M 119M S 0.0 3.4 0:00.04 /usr/lib/libreoffice/program/soffice.bin --splash-pipe=5 It seems odd that it needs 1.6 GB of my 8GB of ram. After 2 hours, my zoom meeting ended, and after closing that program, Libreoffice no longer is taking 4 seconds to refresh the screen. I never used the swap file, that's not the reason. Loading the smaller -c.ods file, updating the data, export, png looks correct. But opening the original ods in the -a.zip up above, did demonstrate the bug. So Guessing the file size, or memory usage is a factor. Then reloading the -c.zip smaller but buggy large chart, it slows down again. So, uncertain if zoom_amd64_5.11.10-4400.deb is relevant.
[Automated Action] NeedInfo-To-Unconfirmed
Not reproducible for me with Version: 7.4.3.0.0+ / LibreOffice Community Build ID: 8bc82b41a97461a6b03e7a678f563b5ad3b4d79d CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Ubuntu_20.04_x86-64 Calc: threaded You are using a very old version not maintained anymore. Please could you upgrade to the current ones, 7.3 or 7.4 ? Best regards. JBF
No repro with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 07aa8138db9bbaf222f2b7cea12a9f7d0a8192d7 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-US Calc: CL threaded please , try newer version. Thank you.
Tried to add stretch-backports to my sources.list, then force version in Package manager, but get error Unable to correct problems, you have held broken packages. It's unable to fix broken packages, so will have to major upgrade the OS to comply with your request. I prefer running stable, not bleeding edge.
Hello, you can try Appimage https://www.libreoffice.org/download/appimage/
(In reply to raal from comment #8) > Hello, you can try Appimage Excellent, I was not aware of this package. Is Nice to get around the dependency headache. The first 2 links in green download buttons are broken. I found working links further down. Looks like the rest of my day will be spent working on configurations and getting the export image to save the same size, and asking questions for what I can't find...
(In reply to S.Andreason from comment #9) > > The first 2 links in green download buttons are broken. I found working > links further down. > reported https://redmine.documentfoundation.org/issues/3623
For those insisting I try newer version, please see new questions (probably bugs yet to be reported) this has spawned: https://ask.libreoffice.org/t/chart-size-will-not-change-for-export-to-image/83056 I am unable to get usable png files, sized 1024 pixels wide. Can you open my sample ods in either zip, and get the larger chart to export at anything other than 943x530 ? I've opened several other ods saved in 5.2.7 and they also fail to resize at export. My specific bug seems to be fixed, but can't really say Works for Me at this point. Thank you
Appears fixed in version 7. I imagine you can mark this report for version 5.2 as Won't fix.
Retract my last statement. I see a problem drawing some line that fits the pattern from before. I didn't inspect the png fast enough to still have the document open. I'll try again to reproduce this bug.
Additional information: Reopened the spreadsheet, export selection, same effect seen. Closing did not reset it. https://www.seahorsecorral.org/images/tests/temps3-6-20221021-v73-unevenLines.png Notice the darker green line between 65-70 on the left axis, the thickness is not consistent across the entire width. It is thin or missing some dots just like the inverted normals in v.5.2 except the line width is only 0.00 From left to right the darker green line becomes correct thickness at 10-06 where the bug jumps to the orange line, lasting through 10-08. I tried increasing the thickness to see if the original bug could be reproduced, but am unable. I think for now I'll just increase to 0.01 which looks good, and see if it comes back in future days.
Created attachment 185527 [details] File with problem Steps: 1. Go to sheet pi5-202112_temp-log-accum-F 2. Right-click chart - Export as Image
(In reply to Buovjaga from comment #15) > Created attachment 185527 [details] > File with problem > > Steps: > 1. Go to sheet pi5-202112_temp-log-accum-F > 2. Right-click chart - Export as Image Ah, the thing I saw is already reported as bug 153544. Maybe we should wait until it is fixed before testing further. Meanwhile S.Andreason could clarify a bit how exactly we should test.
I couldn't reproduce with the following steps: 1. Open attachment 185527 [details], got to the large chart at the top of temp-log-accum-F sheet 2. Edit chart, go to data ranges > series, Remove the 3 series: CPU, GPU, and H_44 > OK 3. Select the AIR_OUT data series, right-click > format, change the line width to 0.04 cm, change to colour to darker colour. 4. Click outside the chart to deselect it, Right click the chart, export to png. Export was instant, chart looks the same as original. Tested with: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cae0daff1dd8bd60208892c792948c0cd2b0eeec CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded There is a lot to this report. Admittedly I didn't try to wait for an hour to export again, but it would be great if you could: - try again with an updated version. Please use a currently supported version: master version from https://dev-builds.libreoffice.org/daily/master/current.html or wait for the release of version 7.5.2 in the next few days, as these two version don't have the bug Buovjaga mentioned. Or test with version 7.4.6. - with the updated version, provide shorter, precise steps that consistently reproduce the issue, if possible at all. Thank you!
Hi, I've been upgrading my OS over the last 2 weeks, since the last month of zoom updates have been so broken on my debian-stretch-amd64 system, and they act like they have dropped support for older operating systems. Seeing the increased activity on this bug, I have made an effort to duplicate my own bug, using the same LibO-7.3 container program, but have not yet gotten this bug to show itself. Since the OS upgrade to bullseye did fix the zoom audio issue, and audacity audio issue, it may be that it also fixes this bug. Tentatively solved. Appears bug was in stretch. Thank you for affirming you could not duplicate it.
No problem, thank you for reporting back. Marking as "worksforme" for now as we're not entirely sure the issue came from outside LibreOffice, but if the issue comes back, feel free to set back to "unconfirmed". All the best!