Description: The output of any diagonal cross-hatch pattern from matplotlib, specifically the 14 (geometric) lines in the "d" attribute of the "path" tag of the SVG pattern definition matplotlib generates causes Writer, Impress, Draw etc. on my Ubuntu 18.04 and 19.10->20.04rc systems to generate spurious solid filled squared between some of the hatch lines. Removing, adding or editing line segments of the pattern line path data suppresses the appearance of this bug in an unpredictable manner. Steps to Reproduce: 1. Have matplotlib.pyplot plot a bar graph, say, using the "x" hatch pattern. 2. Save the plot with plt.savefig("badhatch.svg", dpi=50) 3. (optional) Edit the SVG to include only the pattern and the hatched polygon. 4. Drag the SVG file into Writer, Impress or Draw. Actual Results: The hatching in the image appears with some of the squares bounded by crossing diagonal lines filled with spurious squares, appearing as a giant 45 degree mosaic of light and dark squares. Expected Results: The hatching should appear only as 45 degree crossing lines. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-NZ (en_AU.UTF-8); Calc: group Version: 6.3.4.2 Build ID: 1:6.3.4-0ubuntu0.19.10.1 CPU threads: 2; OS: Linux 5.3; UI render: default; VCL: gtk3; Locale: en-NZ (en_AU.UTF-8); Calc: group
Created attachment 158329 [details] python script to generate fairly minimal test SVG with x-hatching Though the output of this script is fairly small, please see the hand-pruned test SVG also attached. (It is the path data in the pattern definition for the hatch which triggers the SVG importing bug.)
Created attachment 158330 [details] SVG test image produced by badhatch.py The bug-triggering SVG test image produced by the python script via matplotlib. (There is a hand simplified version also.)
Created attachment 158331 [details] lo-sad.svg: Minimalistic SVG which triggers pattern anomaly This SVG is pruned to pretty much the bare minimum that triggers the appearance of spurious filled regions in the rendering of the x-hatch pattern. The appearance of the SVG import bug is very sensitive to the move-to, line-to data in the pattern's line path. Seven right-oblique lines are drawn successively from the top-left corner followed by seven left-oblique lines drawn successively from the lower-left corner.
Created attachment 158332 [details] LibreOffice Writer screenshot (annotated) V6.0.7.3 and V6.3.4.2 both fail to properly import SVGs with hatching of the "x" style from matpltlib. The later version of LibreOffice Writer displays the same spurious filled squares for both lo-sad.svg and badhatch.svg, the output of badhatch.py.
Reproduced in Version: 7.0.0.0.alpha0+ Build ID: 37b4784ca722aa0496cda95191869c2086223e24 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Also reproduced in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11; Locale: en-US (en_US.UTF-8); Calc: group but not in Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; Locale: ca-ES (ca_ES.UTF-8)
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=f5d4a688346a939a58b1df69d771dede177b3370 author Regina Henschel <rb.henschel@t-online.de> 2016-03-16 18:51:48 +0100 committer jan iversen <jani@documentfoundation.org> 2016-03-17 07:43:05 +0000 commit f5d4a688346a939a58b1df69d771dede177b3370 (patch) tree da28053c887986612c955ce8a6fae37d6f802722 parent be2c79c0fab348ade79f20f7a3727be818997d7f (diff) tdf#98599 SVG: consider attributes of 'defs' element Bisected with: bibisect-linux-64-5.2 Adding Cc: to Regina Henschel
Reverting the patch does not solve the problem. I still see the filled squares in file "SVG test image produced by badhatch.py" (=badhatch.svg) after I have reverted the patch. You get the same problem, if you remove all def-elements and g-elements, so that my patch is not involved. So I suspect a different reason. The hatching is OK, if the right-oblique lines are put into one path-element and left-oblique lines are put into a second path-element. So it seems to be a rendering problem.
Dear Daniel Neville, 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
The spurious hatch rendering bug (revealed by dragging lo-sad.svg into a LibreWriter document) persists in Version 7.2.6.2 (the latest normally available for my fresh install of Ubuntu 21.10) Adding ppa:libreoffice/ppa and and installing the updates, I now have: Version: 7.3.2.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-NZ (en_AU.UTF-8); UI: en-US Ubuntu package version: 1:7.3.2~rc2-0ubuntu0.21.10.1~lo1 Calc: threaded The bug still appears exactly as pictured in the "LibreOffice Writer screenshot (annotated)" attachment above.
Also in Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dabedcaf27b0af1e38a611b8d8e48444f848e01d CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Created attachment 190786 [details] sample SVG without defs tags Sample document with <defs> tags removed. Using this sample document, one can see the issue predate Regina's commit, as in comment 8. For example when inserting into a Writer document in LO 4.0.0.3.
Prompted by the e-mail notice of a version 7.6.2 of LibreOffice to try, I installed that and found the hatch rendering bug persists. (Stéphane Guillou’s super-minimalistic, defs-free test SVG also reveals the bug.) The version information copied from Libre Writer: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-NZ (en_AU.UTF-8); UI: en-US Calc: threaded System: Ubuntu 22.04 LTS on a NUC7i5BNH.