Does LibreOffice throw any error code/message while converting password protected file to PDF?

I am using the following command to create PDF file using LibreOffice7.2.5.2:
soffice.exe --headless --convert-to pdf D:\test.docx" --outdir D:\output

test.docx is password protected file and the above command is neither converting it to PDF nor giving any error code/message.

any solution would be appreciated.
Thanks.

Please note that using soffice.exe (note the exe) in command line is discouraged. You should either use soffice without extension, or use soffice.com to use proper command line interface, which is introduced in version 6.3. Otherwise, console output will not appear in the stdout/stderr, and the return from the command will not be passed to the shell (note however, that only error string will be output for failures processing files, not process return code in ERRORLEVEL, which would have some non-0 value only when fatal errors happen, like a crash or invalid command line).

Also the command line you provided has an unpaired quote, which is likely a typo - but please always use copy-and-paste to provide problematic command line exactly as you use it, not re-type it, to allow us to not guess where the real problem is.

(I have amended the related help page - the next 7.4 will have the clarification about soffice.com vs soffice.exe use).

1 Like

Excellent. Thank you @mikekaganski! I learned something.

I see the fail message now in console. Can probably catch it by redirecting stderr and/or stdout. Seems that ERRORLEVEL is still not touched.

Sorry for the typo. I was using the below command:
soffice.exe --headless --convert-to pdf “D:\InputFiles\test.docx” --outdir D:\InputFiles

is there any command-line arguments(something like --outdir) that can give us an error message along with .exe in the command

The problem is that soffice.exe is a GUI Windows application. There are two kinds of Windows applications, one is GUI (windowed), and one is console application. The former one is not attached to the console, even when it’s called from it; and Windows doesn’t provide any ways to ensure that such application can interact with the calling console correctly. There were numerous attempts to workaround that system specific in the past; all of them were unreliable at best, and none allowed to use shell scripts (batch files) anyway; they all broke from one Windows version to another. That was why we needed another - proper console - application; and no, there’s no way we could make .exe work. It’s not possible to start showing dialogs, because it would break any existing use of .exe (which is still the only way for some uses - e.g. where compatibility with other OOo forks is needed).

ok.
so, is there any other command/way to understand whether the file is password protected or not?.
I mean, before converting it to pdf can we identify if the file is protected or not.

No available preparatory measure that I am aware of for detecting encryption state. Best bet is to try, and detect error condition.

In command line you use > to redirect stdout to a file, and 2> redirects stderr.
Append >log.txt 2>err.txt to your command line in order to create a log file for the job and an error file showing the error message.

Something like:

soffice --headless --convert-to pdf D:\test.docx --outdir D:\output >D:\log.txt 2>D:err.txt

Alas, the error file will not show the file name, which makes it less useful if you use wildcards in your command to convert multiple files in one go. Workable for individual converts, but for batch job, subsequently checking for the existence of the result file is probably better. With large batches it may still make sense to create an error file and first check whether that exists. If no errors are output, job completed successfully. No need to confirm individual file’s existence.

Issue

Confirmed using version 7.1.3.2. No message is produced and the error state variable ERRORLEVEL is not set to indicate an error condition. Also, I cannot find any indication in the release notes that this is rectified in the “fresh branch” (version 7.3). Should perhaps test with an install of “fresh” before reporting in the bugtracker.

Workaround

It loooks like you need to check for the existence of target file after running the convert-to-pdf. Something along the lines of

IF [NOT] EXIST %filename%.PDF …

The START ... /WAIT < command > construct is probably required, to ensure that files are created before you try to detect their existence (otherwise, successful conversion may also be detected as failure).