Description: When I open a new or existing drawing and add a short freeform line (about 1 centimeter in length) without filling, the file cannot be saved until this line is deleted again. With longer freeform lines it works, even if they are scaled smaller. If, on the other hand, the short freeform line is scaled larger, the file still cannot be saved. Changing the line thickness and the line style does not change anything either. Translated with www.DeepL.com/Translator (free version) Steps to Reproduce: 1. open a new or existing drawing 2. click on Curves And Poligons an select Freeform Line 3. draw a short Freeform Line round about one centimeter or shorter 4. try to save the file with ctrl+s or file->save or file->save as Actual Results: 5. the massage "Error saving the document <name>: Write Error The file could not be written" appears 6. delete the line 7. saving will work again Expected Results: Saving the File Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Libre Office: Version: 7.0.6.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Ubuntu package version: 1:7.0.6-0ubuntu0.20.10.1 Calc: threaded OS: Kubuntu 20.10 KDE-Plasma-Version: 5.19.5 KDE-Frameworks-Version: 5.74.0 Qt-Version: 5.14.2 Kernel-Version: 5.8.0-63-generic Architecture: 64-bit Computer: Lenovo x230 Notebook CPU: 4 × Intel® Core™ i5-3320M CPU @ 2.60GHz RAM: 7,6 GiB Arbeitsspeicher GPU: Mesa DRI Intel® HD Graphics 4000
I can confirm with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: ba7db98cca3d8516697c94ef0d6af27db9e1655e CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded but not with Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
This seems to have begun at the below commit. Adding Cc: to Armin Le Grand; Could you possibly take a look at this one? Thanks a35ab2611687602ed7c0b9856f2ced2278e31112 is the first bad commit commit a35ab2611687602ed7c0b9856f2ced2278e31112 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Jul 2 18:38:24 2018 +0200 source 36bade04d3780bc54c51b46bb0b63e69789658a5 https://git.libreoffice.org/core/+/36bade04d3780bc54c51b46bb0b63e69789658a5 tdf106792 Get rid of SvxShapePolyPolygonBezier
No problem with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4ac9032163cf55c160145373e7c41741c9c339ca CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL Linux only?
I can confirm this bug with version 7.2.3.
*** Bug 145879 has been marked as a duplicate of this bug. ***
Created attachment 178577 [details] Screenshot of the error message Repro with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4202ea2c932a14d216e74617bbb74a85030c9a59 CPU threads: 14; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (hu_HU); UI: en-US Calc: threaded
*** Bug 148693 has been marked as a duplicate of this bug. ***
Following https://bugs.documentfoundation.org/show_bug.cgi?id=148693#c5, I submitted the patch for review here: https://gerrit.libreoffice.org/c/core/+/133273
Created attachment 179747 [details] Example file saved after patch This file containing one short freeform line was successfully saved when the patch https://gerrit.libreoffice.org/c/core/+/133273 was downloaded and applied to a current-ish master. Before the patch this failed.
Created attachment 179748 [details] The previous example file with a short freeform line after saved
Created attachment 179749 [details] The example file after reloading Interestingly - but this may be another problem - the freeform line disappears from the previous file upon reload. The content.xml contains this markup: <office:body> <office:drawing> <draw:page draw:name="page1" draw:style-name="dp1" draw:master-page-name="Default"> <draw:path draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="0.843cm" svg:height="0.069cm" draw:transform="rotate (-1.24738681640035) translate (2.18620257244169cm 3.89089890473905cm)" svg:viewBox="0 0 844 70"> <text:p/> </draw:path> </draw:page> </office:drawing> </office:body>
Created attachment 179750 [details] Short freeform line saved by 6.0.7 This file saved by 6.0.7 opens in current master correctly, the content.xml contains this markup: <draw:page draw:name="page1" draw:style-name="dp1" draw:master-page-name="Default"> <draw:path draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="0.819cm" svg:height="0.411cm" draw:transform="rotate (-0.707207412908102) translate (2.83327170343278cm 3.81915190015142cm)" svg:viewBox="0 0 820 412" svg:d="M0 14l415-14 405 124-138 288"> <text:p/> </draw:path> </draw:page>
https://odfvalidator.org/ says: freeform-patched.odg/content.xml[2,4046]: Error: element "draw:path" is missing "d" attribute
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fd4410aa5fd079e4277297f1fb70ad8c728e7a17 tdf#145240: Can't save drawing if I'm adding a short freeform line with no fill 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 submitted https://gerrit.libreoffice.org/c/core/+/133400 for 7.3 branch. I'll let the status as it is for the moment, I prefer waiting a bit some more feedback.
(In reply to Julien Nabet from comment #15) > I submitted https://gerrit.libreoffice.org/c/core/+/133400 for 7.3 branch. > ... Patch abandoned following Gabor's comment in https://gerrit.libreoffice.org/c/core/+/133273
(In reply to Gabor Kelemen (allotropia) from comment #13) > https://odfvalidator.org/ says: > > freeform-patched.odg/content.xml[2,4046]: Error: element "draw:path" is > missing "d" attribute @Regina, I thought you might be interested in this issue
Unassign myself since the patch seems wrong. Feel free to revert the patch in 7.4 branch.
This bug also appears in Impress: Version: 7.3.5.2 / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 16; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded If I try to draw a dashed line by hand using the freeform tool, then I cannot save the document; I see a small window with the error message reported in the first post.
Taking a look. 1st try worked as expected: I changed to cm before in Draw, I zoomed in to be able to draw a line shorter than 1cm, save, reload -> no error reported. For 2nd try i did not zoom in, save, reload -> no error reported. BUT the short line disappeared, so seems not to be saved (?) Indeed content.xml has the object, but it contains no "svg:d" data, so no geometrical path data. Thus I see no error, but it's possible to create a data loss. Further experimenting seems to show that it seems to depend on the shape having bezier curves or not: When drawing that shape (important: without zoom!) those very small mouse movements create a multi-edge polygon, but without beziers. When I move a little bit more (still staying below the 1cm limit) I am able to create a bezier, and in that case save, reload shows no data loss. -> Seems as if when the freeform is not a bezier we have that problem...
(In reply to pglpm from comment #19) > If I try to draw a dashed line by hand using the freeform tool, then I > cannot save the document; I see a small window with the error message > reported in the first post. How do you draw a dashed line with the freeform tool nowadays? Before in the sidebar just the PageProperties were shown when no object is selected, it was possible to change the defaults for object creation. That functionality - an important one if you ask me - is gone resp. no longer accessible. How can that be done today?
Have identified the basic problem: In XMLShapeExport::ImpExportPolygonShape in xmloff/source/draw/shapeexport.cxx the Any fetching the geometry using uno::Any aAny( xPropSet->getPropertyValue("Geometry") ); acesses this dependent from the XmlShapeType eShapeType, so tries to always read a bezier for XmlShapeTypeDrawClosedBezierShape and XmlShapeTypeDrawOpenBezierShape. OTOH in SvxShapePolyPolygon::getPropertyValueImpl OWN_ATTR_BASE_GEOMETRY is capable to pack the geometry to a drawing::PointSequenceSequence when no bezier is used. Working on a solution...
Possible fix at https://gerrit.libreoffice.org/c/core/+/141935
Armin Le Grand (allotropia) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/470201f392a019ef6f2b9e70377e66e47e839494 tdf#145240 add flexibility to receiving PolyPolygons over UNO API It will be available in 7.5.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.
Fix checked & comitted