Description: Using: * macOS Catalina 10.15.7 * LibreOffice Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 8; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Editing ODG file drawings has become fraught with frustration. Using a multi-page Draw file. The Draw file contains anywhere between 2 to 8 pages/sheets. Each sheet contains one or more inserted images (PNG/TIFF/SVG), each of which is numbered using a Bezier curve to point to a particular part of the image, and then a text box to add reference number. I can quite happily make multiple changes to a sheet, and save them. However, when I switch from a previously edited sheet to a different sheet, I can again make multiple edits, but if I try to save the file e.g. Cmd-S or File > Save, I get an error message indicating that the file could not be written. The only alternative is to quit LO, losing all the changes I've made since the last save and start again. Using Save as... doesn't work (this is a known bug on macOS). It is intensely frustrating, coupled with the recently acquired slowness to distraction of Draw when editing anything containing more than about 5 objects. This is also a regression over the 6.4.x line, which did not have such undesirable behaviour. Steps to Reproduce: See above description Actual Results: The save procedure should occur normally. Expected Results: The changes to the file should be saved. Reproducible: Always User Profile Reset: Yes Additional Info: The save operation should complete normally, and not fail with some vague and unhelpful error message, or else it should say why it failed in the message.
Please attach a file where this problem happens.
This is linked to bug 138759. I can't attach the file due to professional confidentiality obligations.
Alex: regarding confidentiality, could you try unzipping the ODG, replacing the images with some dummy ones and then re-zipping the thing again? Hopefully the saving failure would be preserved in the sanitised one.
(In reply to Buovjaga from comment #3) > Alex: regarding confidentiality, could you try unzipping the ODG, replacing > the images with some dummy ones and then re-zipping the thing again? > Hopefully the saving failure would be preserved in the sanitised one. If someone can show me how to do that without destroying the ODG on rezip, then I can give it a try. So far, every time I've tried to unzip/rezip an ODF file on MacOS, it kills the file because manifest.xml gets included in the wrong order.
(In reply to Alex Thurgood from comment #4) > (In reply to Buovjaga from comment #3) > > Alex: regarding confidentiality, could you try unzipping the ODG, replacing > > the images with some dummy ones and then re-zipping the thing again? > > Hopefully the saving failure would be preserved in the sanitised one. > > If someone can show me how to do that without destroying the ODG on rezip, > then I can give it a try. So far, every time I've tried to unzip/rezip an > ODF file on MacOS, it kills the file because manifest.xml gets included in > the wrong order. Maybe in the console, while being inside the unzipped directory: zip -r -X drawing.odg ./ The -X option is supposed to skip adding the invisible macOS resource files. Alternatively, use 7-zip console application: https://www.7-zip.org/a/7z2102-mac.tar.xz The syntax for 7-zip is 7z a -tzip drawing.odg ./* based on this guide https://info.nrao.edu/computing/guide/file-access-and-archiving/7zip/7z-7za-command-line-guide and some info I found about preserving the directory structure. Didn't test, but hopefully it would work.
we still wait some example => NEEDINFO
Unfortunately, the drawings which display the behaviour are covered by legal privilege. They tend to be exported views of fairly complex mechanical devices with many components which are integrated into drawings for patent applications.
[Automated Action] NeedInfo-To-Unconfirmed
With the recent fixes that have gone into 7.5 and 7.6, no longer reproducible. Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded