Description: Trying to convert documents between formats results in error message "Error: source file could not be loaded". Steps to Reproduce: 1. Download any AppImage from appimages.libreitalia.org website 2. Run in terminal "LibreOffice.AppImage --convert-to docx *.odt" 3. Error message shown in description above will appear Note: this error happens when converting between any format, not just odt to docx. Actual Results: Error message is shown, and document(s) are not converted. Expected Results: Document conversion should succeed with the message "convert Document.odt as a Writer document -> Document.docx using filter : MS Word 2007 XML" Reproducible: Always User Profile Reset: Yes Additional Info: This error happens on all appimages on the appimages.libreitalia.org repo. Extracting the appimage then running the soffice.bin binary to convert documents works however.
Please upgrade a recent LO version 7.6.4. Indeed 7.2 branch is a bit old (2021/2022, see https://wiki.documentfoundation.org/ReleasePlan/7.2)
(In reply to Julien Nabet from comment #1) > Please upgrade a recent LO version 7.6.4. Indeed 7.2 branch is a bit old > (2021/2022, see https://wiki.documentfoundation.org/ReleasePlan/7.2) Sorry, I should have clarified: it happens on all appimages from 7.2 to the latest (24.2). The 7.2 I put in the bug report is the oldest version I could find where the bug happens.
Ok, would it be possible you attach an example file so we can give it a try ? Don't forget to sanitize the file if needed (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission).
Created attachment 192622 [details] empty document created in LO 7.6 in safe mode Here is the document. FYI, all types of documents cannot be converted, including spreadsheets (.ods), presentations (.odp), and drawings (.odg). Doesn't matter if the documents are empty or has content; LO appimage will fail to convert any file given to it.
[Automated Action] NeedInfo-To-Unconfirmed
With LO Debian package 24.2.0.3, I don't reproduce this. I suppose it's specific to AppImage version. Can't help here => uncc myself.
With the AppImage, file names have to be absolute paths instead of relative. Otherwise it will look in the directory where it is mounted. For example, something like this would work: LibreOffice.AppImage --convert-to docx /home/stragu/Downloads/sample.odt --outdir /home/stragu/Downloads/ Alternatively, you can use readlink. For example: LibreOffice.AppImage --convert-to docx $(readlink -f sample.odt) --outdir $(readlink -f .) Emiliano, is this something that could be improved on at all on https://git.libreitalia.org/libreitalia/loaih ? (setting to "new" as the issue is reproducible, although I'm not sure what can be done and where it should be done) Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #7) > With the AppImage, file names have to be absolute paths instead of relative. > Otherwise it will look in the directory where it is mounted. Confirming, it seems quite standard behaviour with AppImages to me: https://github.com/AppImage/AppImageKit/issues/479 > Emiliano, is this something that could be improved on at all on > https://git.libreitalia.org/libreitalia/loaih ? At worst it will require a change of the toolkit inside the script; more generally, I am not sure I can deliver *at all* (my efforts until now were just porting the previous script to Python, providing a new interface and automating the builds). But of course I will look into it. > (setting to "new" as the issue is reproducible, although I'm not sure what > can be done and where it should be done) I agree; generally, AppImages are to be considered a community effort, unless the ESC would decide otherwise. Unfortunately I cannot provide development or other kind of support activities for AppImages (for sure, alone).
OK, let's close as "not our bug" then. Thank you Emiliano! Are you OK to open an issue on your repo, to track it and link it to this report?
(In reply to Stéphane Guillou (stragu) from comment #9) > Are you OK to open an issue on your repo, to track it and link it to this > report? https://git.libreitalia.org/libreitalia/loaih/issues/4 Unfortunately, the Gitea has no public access, at least for the moment - feel free to peruse this bug ID or, maybe better, contacting me in private.
Thank you! :)