I use LibreOffice to create PDF files from writer .odt files for my product build process. As such, I do the equivalent of the following command from my build scripts... swriter -invisible -nodefault -nolockcheck -headless -writer --convert-to pdf -outdir "%outdir%" "%tofile%" It works just fine standalone, good stuff!!! But... If I have a "manually run" LibreOffice writer instance running with an open document (whether it's minimised or not), I always get a new empty "Untitled <nnn>" window for each document I convert in my build process. This is rather frustrating because it works fine if there's no window already open when I invoke the build. I've even tried "soffice -writer" instead and it doesn't seem to make a difference... Standalone works fine, already open window get's an "Untitled <nnn>" window for each document. Note: I substitute a Window's full path for %outdir% and a pathless filename in %tofile%, running with the "current directory" set to the directory the file %tofile% is in. Note: I've tried all the combinations of "-headless" "-invisible" "-nodefault" and everything else I can think of in different combinations. Note: I use Window's kernel32.dll CreateProcess to invoke the swriter instead of invoking it from cmd.exe, so it's not a problem having to do with cmd.exe -- I control the process invocation in my own C++ code, so there's no other code involved here except my code, LibreOffice, Java runtime, and Windows itself!!! Please help. Thanks, Bruce Ferris
Behaves same way in 3.4.4 and 3.4.5
AFAIK, you can't have two instances of LibreOffice running with the same profile. I suggest you to try with another profile, a profile dedicated to these conversions. To do that you can use -env:UserInstallation=pathfile option. Best regards. JBF
@ BEFE Software Please, tell: with -env:UserInstallation=%pathfile% option it works?
Jean-Baptiste, thanks for the reply but, quite honestly, I can't find any documentation anywhere that tells me what %profile% is in "-env:UserInstallation=%pathfile%"... I suppose, since you're using the '%', you're talking about a Windows style environment variable. Okay, let's assume it is... What is a PROFILE? I don't see any documentation that jumps out at me telling me about those either. Is it a separate unique file name, is it something I have to configure or is it more complex than that? Not just that, I'm currently in Ubuntu/Linux mode because I'm also a software developer and that's the platform I'm currently working on (it was Windows when I logged the ticket). So I find the reference to '%profile%' a little bit suspicious. If you could point me to somewhere that "-env:UserInstallation=..." is documented I'll give it my best effort to answer your question. By the way, it works just fine if I do NOT have another LibreOffice running, so you're most likely right about the profiles. But, WHAT IS A PROFILE and, more importantly from a user perspective, WHY SHOULD I CARE about profiles? Thanks Bruce Ferris
Profile is where all your personalizations for LO are stored. For LO up to 3.4.5 it is stored in ~/.libreoffice For LO from 3.5.0 it is stored in ~/.config/libreoffice In these folder you can see another folder named 3, this folder is your LO profile. I suggest you to duplicate this folder in 3_bis and use this second profile. Here is a script I use to launch LO 3.4 with a profile of my choice: #!/bin/sh MY_CONF=file:///home/<your_login>/.libreoffice/3_bis/ /opt/libreoffice3.4/program/soffice -env:UserInstallation=${MY_CONF} "$@" modify accordingly to your settings and save these 3 lines in a text file, make it executable and launch it in a terminal. Best regards. JBF
@ BEFE Software Sorry for misunderstanding. And, please, verify if it works with script with previous comment
After a bit of confusion and soul-searching on my part I finally got it working properly with the "-env:UserInstallation=file://..." command line parameter on WINDOWS -- the main problem I had was that my own software that invoked the soffice executable was in the middle of going through an Ubuntu port -- so I had to get the Windows port of my own software working enough, again, to test this bug. But, that does get around the immediate problem. Thanks for the temporary solution. Interestingly enough, the Ubuntu 11.10 port of LibreOffice that I am using does not have the same restriction -- meaning it doesn't care if another soffice process is running. I do wonder what design/implementation requirement demands that on the Windows platform but not on Linux/Ubuntu i386 platforms. Hmmmm. So, I wouldn't be completely satisfied at this point to flag this Bugzilla ticket as "Resolved". Do you understand why I take that position? Anyway, thank you very much for your time and attention. Bruce Ferris
(In reply to comment #7) [...] > I do wonder what design/implementation requirement demands that on the Windows > platform but not on Linux/Ubuntu i386 platforms. Hmmmm. > > So, I wouldn't be completely satisfied at this point to flag this Bugzilla > ticket as "Resolved". Do you understand why I take that position? You should ask on dev mailing list for explanations. I am afraid that is a MS-Windows limitation. Best regards. JBF
@ BEFE Software Thanks for additional testing. And about Ubuntu: it contains only one version of LibreOffice installed? (releases and beta versions hold their files in different folders, so my start independently. And previous version hold files inside of ~/.libreoffice, and current version inside of ~/.config/libreoffice so old and current version can also used independently and simultaneosly)
Jean-Baptiste, I did further investigation on my Ubuntu claim, and it turns out that you were right... It does act the same way in Ubuntu as it does on Windows -- I must not have been paying close enough attention when I asserted the two platforms behaved differently. I don't have multiple LibreOffice installations on my Ubuntu machine -- at least none that I can detect. And, the work around with "-env:UserInstallation=file://..." fixes the problem on Ubuntu as well. So, in my case, I have worked around this in my own software by invoking "soffice -env:UserInstallation=file://..." and everything works just fine now. Good stuff!!! If you wish, you can change this bug to "Resolved" but I am still a bit uneasy about that because... A) I don't have a reasonable explanation of why separate "empty windows" could possibly be required when I specify "--invisible" and other settings to mean "I don't need any GUI interaction, just DO IT!!!". So, it seems the requirement is something oddly internal to LibreOffice on multiple ports or, possibly, a simple "that got overlooked" type of bug. B) Once again, I couldn't find "-env:UserInstallation=..." mentioned anywhere obvious in the technical documentation -- although this may be my own deficiency because I could just be looking in the wrong places as I'm not a LibreOffice guru -- just an "end user". I will however, as soon as I can get the time, check out the dev mailing list, figure out what that is about (because I haven't used it before) and submit the query there. Thank you very much for your time and effort in resolving this for me. Bruce Ferris
Thanks for additional testing on Ubuntu. Workaround need not because we not want to fix bug, but because LibreOffice should to work properly right now, and fixing bug my take much time.
The "-env:UserInstallation=..." command line parameter is explained in the help of version 3.4 but not in the help of 3.5. I do not know why. If you confirm, you can file another bug report for this problem. Setting as resolved / worksforme (did not find better). Feel free to reopen if needed. Best regards. JBF