Created attachment 93886 [details] Sample A4 ODS file becoming Letter-sized PDF with --headless conversion I'm trying (on Mac OS X Mavericks) to use an ODS/Spreadsheet file to dynamically create a PDF (which is meant to serve as my letterhead/background for other documents I write). My whole workflow is controlled by a Makefile which uses a "soffice --headless" command. Here is the problem: 1. Creating the PDF manually by using the LO/Spreadsheet GUI "Export as PDF..." creates a 2-page A4-sized PDF document (as expected). 2. Using the "--headless" commandline creates a 4-page Letter sized PDF document (useless for my further workflow). A sample ODS file ('lh-dummy.ods') is attached. I can reproduce this outside of the Makefile environment, purely on the commandline, like this: /Applications/LibreOffice.app/Contents/MacOS/soffice \ "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" \ --headless \ --convert-to pdf:calc_pdf_Export \ --outdir $(pwd)/l \ $(pwd)/lh-dummy.ods * --headless: this param suppresses popping up the LO GUI * "-env:...": this param allows to run a 2nd independent LO instance headlessly even while a GUI instance of LO is open. The result is a Letter-sized, 4-page PDF file named "lh-dummy.pdf" in the automatically created directory "./lo". Loading the same ODS into LibreOffice and exporting to PDF will create a 2-page, A4 PDF.
(In reply to comment #0) > The result is a Letter-sized, 4-page PDF file named "lh-dummy.pdf" in the > automatically created directory "./lo". Unable to reproduce under GNU/Linux using: - v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a - v4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 - v4.3.0.2 Build ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409 - v4.4.0.0.alpha0+ Build ID: 3fdd4f069d5436cf39708004af7fda8175fbc4c2 (2014-07-09) ... with this command: /opt/libreofficeXXX/program/soffice --headless --convert-to pdf:calc_pdf_Export lh-dummy.ods In all cases an A4 page sized PDF is created from the provided ODS.
Sorry to difficult to reproduce. But did you update to OS X 10.10.1? Does this persist with LO 4.4.0.1? http://www.libreoffice.org/download/pre-releases/ Interesting that this seems to work on Linux.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-07-18
I've re-tested this, now with this LibreOffice version on Mac OS X 10.9.5 (Mavericks): Version: 4.4.4.3 Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8 Locale: en.UTF-8 I'll upgrade to LibreOffice 4.4.5 now and test again.
(In reply to foss from comment #2) > Sorry to difficult to reproduce. But did you update to OS X 10.10.1? Does > this persist with LO 4.4.0.1? > http://www.libreoffice.org/download/pre-releases/ > > Interesting that this seems to work on Linux. I've got my reasons for staying on OS X 10.9.5, and I'm not going to upgrade the OS for the sake of and on the vague chance that this LO-specific bug may be gone on Yosemite.
Re-tested, still on OS X 10.9.5, with the following LibreOffice version: Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99 Locale: en.UTF-8 Bug status still the same: output is 4 pages (instead of 2), page dimensions are Letter (not A4).
One more test, this time with user interface locale switched to German (I usually use English): Version: 4.4.5.2 Build-ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99 Gebietsschema: en.UTF-8
Created attachment 117882 [details] Screenshot of PDF document on OSX 10.10.4
No repro on OSX 10.10.4 with LO 5.0.0.5 after launching script from Terminal.
Problem seems limited to OSX 10.9.5.
(In reply to Alex Thurgood from comment #10) > Problem seems limited to OSX 10.9.5. Not for me. I have noticed the in 10.9.2 for the first time. Since 2 days ago, I've upgraded to OS X 10.10.4 and LibreOffice 5.0.0. The problem is still occurring for me.
(In reply to Alex Thurgood from comment #8) > Created attachment 117882 [details] > Screenshot of PDF document on OSX 10.10.4 Alex, what was the exact command line you used? Same as mine?
Ok, I came closer to find the culprit: * If I close down a running LibreOffice instance I can also skip the parameter "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" from my command line. In this case, the resulting PDF has A4 page format. However, I *need* to use this parameter, because I have cronjob-ed scripts and Makefiles which ought generate PDFs from ODS documents *while an interactive LO instance is also open", and I cannot every time close it (I don't even know in advance when it will happen)! I tried to find where in my generated `/tmp/LibO_Conversion__${USER}` structure is a setting which enforces the Letter page size, but so far could not identify it. Does anyone have any idea/knowledge about this?
(In reply to kurt.pfeifle from comment #13) > Does anyone have any idea/knowledge about this? I guess that's the locale setting (under Tools->Options...->Language Settings->Languages). Different locales have different default page sizes. So it might be that your system locale is a such one.
(In reply to Maxim Monastirsky from comment #14) > (In reply to kurt.pfeifle from comment #13) > > Does anyone have any idea/knowledge about this? > I guess that's the locale setting (under Tools->Options...->Language > Settings->Languages). Different locales have different default page sizes. > So it might be that your system locale is a such one. In that case we'd need to get access to a command line variable to override that setting. OTOH, when I use `${USER}` in my command line, the environment created in `/tmp/` does contain my real user name -- so why does it not create the identical environment which I have when using LO GUI interactively?!?
(In reply to kurt.pfeifle from comment #15) > In that case we'd need to get access to a command line variable to override > that setting. ... or instead of creating a temporary user profile, you can create a profile and launch it in GUI mode once to set the locale setting there, and then reuse this profile in your script. > so why does it not create the > identical environment which I have when using LO GUI interactively?!? Are you sure that you never changed these settings? Do the locale listed in the GUI in Tools->Options is the same as your system one?
(In reply to Maxim Monastirsky from comment #16) > ... or instead of creating a temporary user profile, you can create a > profile and launch it in GUI mode once to set the locale setting there, and > then reuse this profile in your script. Another suggestion: Under Linux you can set the locale with an env. variable. I'm not familiar with Mac, but suspect that there should be something similar. But still - we need to confirm that it's indeed related to locale settings.
I usually run my MacBook with an English (US) GUI (while using a German keyboard layout). I now switched to German for all GUI/menu settings and rebooted. The LO 5.0.0 language settings are also in German now. Inside my Terminal.app window, the shell command `locale` returns these values: $> locale LANG="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_CTYPE="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_ALL= This command: /Applications/LibreOffice\ 5.0.0.app/Contents/MacOS/soffice \ "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" \ --headless \ --convert-to pdf:calc_pdf_Export \ --outdir $(pwd)/lo \ lh-dummy.ods *STILL* creates a Letter-sized PDF. This command: /Applications/LibreOffice\ 5.0.0.app/Contents/MacOS/soffice \ --headless \ --convert-to pdf:calc_pdf_Export \ --outdir $(pwd)/lo \ lh-dummy.ods creates an A4-sized PDF.
(In reply to kurt.pfeifle from comment #18) > This command: > > /Applications/LibreOffice\ 5.0.0.app/Contents/MacOS/soffice \ > --headless \ > --convert-to pdf:calc_pdf_Export \ > --outdir $(pwd)/lo \ > lh-dummy.ods > > creates an A4-sized PDF. Could you please open the GUI, and tell us what do you have there in "Locale setting"? Does it have a "Default" prefix (e.g. "Default - German (Germany)")? If it doesn't have this prefix, it means that it didn't detect that locale, and you set it manually at some point. BTW, for me under Linux (Fedora 22 64-bit), exporting the LANG variable with different locales does affect the page size of the PDF. (Tried with your file, and with the same command.)
(In reply to Maxim Monastirsky from comment #19) > (In reply to kurt.pfeifle from comment #18) > > This command: > > > > /Applications/LibreOffice\ 5.0.0.app/Contents/MacOS/soffice \ > > --headless \ > > --convert-to pdf:calc_pdf_Export \ > > --outdir $(pwd)/lo \ > > lh-dummy.ods > > > > creates an A4-sized PDF. > Could you please open the GUI, and tell us what do you have there in "Locale > setting"? Does it have a "Default" prefix (e.g. "Default - German > (Germany)")? If it doesn't have this prefix, it means that it didn't detect > that locale, and you set it manually at some point. I doesn't have the "Default" prefix (for German, it would be "Standard"). See the screenshot I will attach shortly. (Second screenshot to show the "Standard" prefix dropdown item which could be selected.) > BTW, for me under Linux (Fedora 22 64-bit), exporting the LANG variable with > different locales does affect the page size of the PDF. (Tried with your > file, and with the same command.)
Created attachment 117904 [details] Screenshot of LO 5.0.0 UI language/menu settings
Created attachment 117905 [details] How German UI language settings look if menu item with "Standard" prefix is selected
Well, actually I meant the second combobox, not the first. Does it also have "Standard - Deutsch (Deutschland)"? Also try to export LC_PAPER="de_DE.UTF-8". I really hope that at least this will work.
(In reply to Maxim Monastirsky from comment #23) > Well, actually I meant the second combobox, not the first. Does it also have > "Standard - Deutsch (Deutschland)"? Yes it does. I tried all (four) combinations already... > Also try to export LC_PAPER="de_DE.UTF-8". I really hope that at least this > will work. Nope. I even tried it with with having the `-env:...` argument twice on the command line, like this: "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" \ "-env:LC_PAPER=de_DE.UTF-8" Didn't help -- output PDF pages are letter-sized.
(In reply to kurt.pfeifle from comment #24) > "-env:LC_PAPER=de_DE.UTF-8" No, it won't work that way. "-env" is not for env. variables, but for LibreOffice internal variables. You should just put LC_PAPER="de_DE.UTF-8" in the beginning of the command (i.e. $> LC_PAPER="de_DE.UTF-8" soffice --headless etc.), or do $> export LC_PAPER="de_DE.UTF-8" before running soffice.
(In reply to Maxim Monastirsky from comment #25) > (In reply to kurt.pfeifle from comment #24) > > "-env:LC_PAPER=de_DE.UTF-8" > No, it won't work that way. "-env" is not for env. variables, but for > LibreOffice internal variables. Thx. Now I know. I tried it for the chance... > You should just put LC_PAPER="de_DE.UTF-8" > in the beginning of the command (i.e. $> LC_PAPER="de_DE.UTF-8" soffice > --headless etc.), or do $> export LC_PAPER="de_DE.UTF-8" before running > soffice. That's what I tried of course too!
OK, I'm giving up. Have no clue why it doesn't work for you.
(In reply to Maxim Monastirsky from comment #27) > OK, I'm giving up. Have no clue why it doesn't work for you. Thanks for your effort, Maxim. You provided new ideas to test, which were indeed worth checking out...
How about export LC_PAPER=A4
Alternatively, you could try installing the en_GB langpack, where the default page size for English should be A4
(In reply to Alex Thurgood from comment #29) > How about > > export LC_PAPER=A4 I tried this -- didn't help.
(In reply to Alex Thurgood from comment #30) > Alternatively, you could try installing the en_GB langpack, where the > default page size for English should be A4 I'm on an extremely slow internet connection right now -- will try later, once this condition is over.
@kurt : any news on recent testing with a GB langpack ?
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team This INVALID Message was generated on: 2016-05-09
In response to comment #34... (Sorry, due to being handicapped by illness, I lost track of this bug for too long.) I can confirm, that this bug is still hitting me, now with version LO v5.4.1.2 Re. a): Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527; CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; Locale: de-DE (en_US.UTF-8); Calc: group Re. b): Steps to reproduce are already clearly described in original bug report. (If you need more details, please specify them.) Re. c): Test file already submitted with original bug report (see first attachment). Re. d): Screenshot already with original bug report (resulting PDF still looks the same latest version of LO, see second attachment). Re. e): I read all comments again and re-tested all suggested fixes and workarounds. Still no dice...
Updated my Version to v5.4.2.2 just now: Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; Locale: de-DE (en_US.UTF-8); Calc: group No change re. this bug.
(In reply to kurt.pfeifle from comment #36) > Locale: de-DE (en_US.UTF-8); > Calc: group > > No change re. this bug. And with a GB lang pack instead of US ?
Created attachment 137602 [details] Screenshot with LO language settings set to "English (GB)"
Created attachment 137603 [details] Screenshot with "About LibreOffice"
I now installed an additional GB lang pack. Set all language and locale settings to "English (UK)". Restarted LibreOffice even (the GUI). See attached screenshot. Same thing for command line PDF creation. Same thing, whether... (1) ...LibreOffice GUI currently is open + running, or (2) ...LibreOffice GUI currently is closed. Also I'm wondering about the following info in the "About LibreOffice" window now. It says: Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; Locale: en-GB (en_US.UTF-8); Calc: group What does it mean when it says under "Locale" in parentheses: "(en_US.UTF-8)" ?? See other screenshot.
(In reply to Alex Thurgood from comment #37) > And with a GB lang pack instead of US ? What should make me think that a GB lang pack would suddenly default to a ISO/metric paper size such as A4, instead of one of their "imperial" ones? Have I been missing something in recent history? (Honest question, no sarcasm...)
(In reply to kurt.pfeifle from comment #41) > (In reply to Alex Thurgood from comment #37) > > What should make me think that a GB lang pack would suddenly default to a > ISO/metric paper size such as A4, instead of one of their "imperial" ones? > Have I been missing something in recent history? (Honest question, no > sarcasm...) Apparently, the DIN standard was adopted by the UK in 1959. This was then adopted as ISO 216 in 1975.
Hmmm, still no repro for me I'm afraid with: Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 Threads CPU : 4; OS : Mac OS X 10.13.1; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
(In reply to kurt.pfeifle from comment #40) > > What does it mean when it says under "Locale" in parentheses: > "(en_US.UTF-8)" ?? See other screenshot. I am assuming that this is the locale that is picked up from the OS system preferences ?
(In reply to Alex Thurgood from comment #44) > (In reply to kurt.pfeifle from comment #40) > > > What does it mean when it says under "Locale" in parentheses: > > "(en_US.UTF-8)" ?? See other screenshot. > > I am assuming that this is the locale that is picked up from the OS system > preferences ? Alex, I have no idea how the locale settings get communicated into LibreOffice. However, I confirm that I'm using my macOS system with an English user interface.
Created attachment 138015 [details] Sample ODS file with Letter size for "--headless" conversion to PDF. Test please: does it remain Letter, or does it become an A4 when converted to PDF? I'm providing a new version of my sample ODS file. It is set to letter size page format. To check, if a "--headless" conversion to PDF preserves the page size, I ask those who want to verify this bug report to use it for testing. Especially interesting are tests run on systems using... -- locale settings to non-English ones, where by default you are using A4 page sizes. -- any other OS than macOS -- where you have forced your default page size to be A4. This is to find out if this problem... -- applies only to "A4-ODS become Letter-PDFs" (as I experience on macOS since a few years, where I use an English GUI with A4 default page size), or -- also extends to "Letter-ODS become A4-PDFs" (if you are on other OSes, or using other locale and a default A4 page size). Thanks for testing.
Created attachment 138016 [details] Sample ODS file with A4 size for "--headless" conversion to PDF. Test please: does it remain A4, or does it become Letter when converted to PDF? This replaces the originally used "lh-dummy.ods" as the A4 input file. The new file name "lh-dummy-a4.ods" makes its clearer what its purpose is, especially when comparing output results achieved with testing "lh-dummy-letter.ods".
Linux users can now very easily generate an "AppImage" executable for LibreOffice which can be used on almost any (old and new) Linux distribution in order to TEST THIS BUG AS WELL AS ANY OTHER BUG IN BUGZILLA ! This also works for almost any historic LibreOffice release. You can now create your own fully functional AppImage binaries of LibreOffice for all releases from the past years up to the newest nightly developer build. Just run the Bash script "make_libreoffice_appimage" hosted on GitHub (you do NOT need to become root!): * https://github.com/antoniofaccioli/libreoffice-appimage These AppImages are generated from input files consisting of official Debian binary builds released by The Document Foundation. You also can include the language pack you'd like or need for your environment. Details are in the README: * https://github.com/antoniofaccioli/libreoffice-appimage/blob/master/README.md You can use the AppImage side-by-side, without conflicting with your existing LibreOffice packages, which are and remain under the control of your local Linux package management system. Since an AppImage is not "installed" and does not mess with your system libraries it is also very easy to get rid of it again, if you do not like it: just delete the 1 file, that the AppImage is. =================================================================================== With this out of the way, here is how I tested the current problem (again), but this time on a Debian Stretch system: 1. Generate an AppImage for LibreOffice 6.1.0.0-alpha0 ------------------------------------------------------ # Prepare an "lo-tmp" directory and get the script: $ mkdir $HOME/lo-tmp $ cd $HOME/lo-tmp $ base_url=raw.githubusercontent.com/antoniofaccioli/libreoffice-appimage $ wget https://${base_url}/master/make_libreoffice_appimage $ chmod a+x make_libreoffice_appimage # The original script may still have '#!/bin/bash -x' in its first line. # Unfortunately his makes the included help output unreadable. Hence we modify it: $ echo '#!/bin/bash' > new_hashbang $ cat new_hashbang make_libreoffice_appimage > new_make_libreoffice_appimage $ chmod a+x new_make_libreoffice_appimage # Read the options of the script: $ ./new_make_libreoffice_appimage # Generate a LibreOffice AppImage for the latest "daily" release, with # German locale included, and see how long it takes. $ time ./new_make_libreoffice_appimage daily de N N N # Generate a LibreOffice AppImage for the latest "fresh" release, with # French locale as well as the respective French off-line help files # included, and see how long it takes. $ time ./new_make_libreoffice_appimage fresh x86-64 fr Y N N I myself will stick with the `... daily de N N N` parameters for now... The resulting AppImage is automatically set to be executable by the script. It is named "LibreOfficeDev-6.1.0.0.alpha0_2017-11-26.de.help-x86_64.AppImage" and resides in the "$HOME/lo-tmp/out" directory. You can move it to any place you want (even a USB thumbdrive) and execute it from there. It is "portable" and this way can be used on your other Linux systems as well. Start your brand-new AppImage for a test by just running $ ./out/LibreOfficeDev-6.1.0.0.alpha0_2017-11-26.de.help-x86_64.AppImage You are even free to re-name the AppImage, and then run it just the same: $ mv ./out/LibreOfficeDev-6.1.0.0.alpha0_2017-11-26.de.help-x86_64.AppImage lo $ ./lo Or put the AppImage into $HOME/bin (that IS in your $PATH, isn't it?!?) and run it without bothering for giving a path: $ cp lo $HOME/bin/ Short test: $ lo --help Just don't forget that it's an AppImage, even though the suffix is no longer there :-) 2. Use AppImage to run tests concerning this current bug -------------------------------------------------------- Now... Since this bug concerns a "--headless" run -- can the AppImage be used to test this bug? Sure. I noticed that on Linux I do not need to call the "soffice" executable (like on macOS). So it is even easier to test headless conversion of ODS/ODT input files to PDF documents. $ lo \ "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" \ --headless \ --convert-to pdf:calc_pdf_Export \ --outdir $(pwd)/l \ $(pwd)/lh-dummy-a4.ods $ lo \ "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" \ --headless \ --convert-to pdf:calc_pdf_Export \ --outdir $(pwd)/l \ $(pwd)/lh-dummy-letter.ods 3. Check page size of generated PDF files ----------------------------------------- $ pdfinfo l/lh-dummy-letter.pdf | grep "Page size:" Page size: 611.972 x 791.972 pts (letter) $ pdfinfo l/lh-dummy-a4.pdf | grep "Page size:" Page size: 611.972 x 791.972 pts (letter) This means: the bug is still there. Regardless of A4 or Letter page size in the input, the PDF output will always be Letter. Here are my `locale` settings: $ locale LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= =================================================================================== Ok, since I did all of the above steps on a Linux Debian system, and running LibreOffice 6.1 Alpha, I now conclude: 1. This bug is present on all OSes 2. This bug is present on all versions of LO 3. This bug can be re-opened as CONFIRMED and I will change the bug's status accordingly. Now have fun testing other bugs with the an AppImage generated by the script as outlined above! Just generate an AppImage for any version/language combo you need to test. (Don't rename the original AppImage in order not to loose the version/language info. You can use symlinks with more comfortable names if you want them.) ---- And finally: Thanks to Antonio Faccioli for creating and maintaining his extremely useful script to generate AppImages as well as his openness to include suggestions and merge pull requests!
Ah, ugghh... I cannot set a status of "CONFIRMED" for this bug. Oh, well...
So I created myself a few different AppImages: * First available release from 3.x.x.x series * Last available release from 3.x.x.x series * First available release from 4.x.x.x series * Last available release from 4.x.x.x series * First available release from 5.x.x.x series * Last available release from 5.x.x.x series * First available dailybuild 6.1.0.0.Alhpa0+ Unfortunately none of the 3.x.x.x ones did produce any PDF output for me. Some did not even run in --headless mode, because they are looking for Java and telling me: "javaldx failed. User must select a JRE from options dialog!" But the 4.x.x.x and 5.x.x.x all converted the ODS to PDF. ============================================================================ # Testing all LibreOffice versions available to me as AppImages: $ cd out $ for i in LibreOffice-*.AppImage ; do j=${i%%.AppImage} time ./$i \ "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" \ --headless \ --convert-to pdf:calc_pdf_Export \ --outdir $(pwd)/${j/LibreOffice-/} \ $(pwd)/lh-dummy-a4.ods ; exitcode $? ; echo "Converting with $i DONE with exitcode $exitcode" ; echo done ============================================================================ From the command looping through all the AppImage versions I had built, I learned these additional things (which I did not investigate further): 1. Version 3.3.0 completed the PDF output with exit code 127. It did not produce any PDF output. 2. Version 3.5.7rc2 completed the PDF output with exit code 139. It did not produce any PDF output. 3. Version 3.4.6rc2 produced no PDF output, but created the output directory with a file inside named ".~lock.lh-dummy-a4.pdf#". The contents of this file was a comma-separated line of ASCII strings looking like this ("kp" is the username I'm using): ,kp,<fq-hostname>,27.11.2017 23:18,,file:///tmp/LibO_Conversion__kp;kp ============================================================================ ##################################################################### # As a side result from this investigation I observed that version # # 5.2.2.2 was significantly slower in producing PDF output in # # headless mode than any version before or after. # ##################################################################### # But now for the bug that I'm interested to get solved: $ for i in */*.pdf; do echo -n " $i:"; pdfinfo $i | grep "Page size"; echo ; done ============================================================================ I got these results: 4.0.0.1.de.help-x86_64/lh-dummy-a4.pdf: Page size: 612x792 pts (letter) 4.4.7.2.de.help-x86_64/lh-dummy-a4.pdf: Page size: 612x792 pts (letter) 5.0.0.1.de.help-x86_64/lh-dummy-a4.pdf: Page size: 612x792 pts (letter) 5.3.7-x86_64/lh-dummy-a4.pdf : Page size: 612x792 pts (letter) 5.4.3.2.de.help-x86_64/lh-dummy-a4.pdf: Page size: 611.972x791.972 pts (letter) 5.4.3-x86_64/lh-dummy-a4.pdf : Page size: 611.972x791.972 pts (letter) 6.1.0.0.alpha0-x86_64/lh-dummy-a4.pdf : Page size: 611.972x791.972 pts (letter) +============================================================================+ | | | 1. None of the versions did carry my A4 page size from the input ODS into | | the headlessly generated PDF. | | | | 2. Now it's your turn again, guys! | | | +============================================================================+ ( Also, as another side effect from this investigation: we can see that after v5.3.7 and before v5.4.3 the precision of putting the page size dimensions into the PDF somehow must have been upgraded by somebody, isn't it? )
I wonder what if a new page style other than "Default" is created and such page style is applied to the file.
hmmm, it seems my guess in previous comment is wrong.
Dear kurt.pfeifle, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This is very long bug that nobody ever confirmed, but reporter - which is not by BZ rules. Basically, test ODS conversion to PDF of Letter attachment 138015 [details] and A4 attachment 138016 [details]. In my case, works OK in headless. Key is using "-env:UserInstallation=file:///tmp/LibO_Conversion__${USER}" which wasn't explained how it was created, only explained why used in Comment 13. Best advice here was Comment 16 but I didn't notice it was followed. With all, seems NotABug.
User profile is somewhat explained in bug 141960. Help on headless is not well.