Bug 74861 - [Spreadsheet] Exporting A4-sized ODS to PDF with '--headless' creates Letter-sized PDF (where manual export via GUI creates A4)
Summary: [Spreadsheet] Exporting A4-sized ODS to PDF with '--headless' creates Letter-...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2014-02-11 21:57 UTC by kurt.pfeifle
Modified: 2018-12-09 20:33 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample A4 ODS file becoming Letter-sized PDF with --headless conversion (27.65 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-02-11 21:57 UTC, kurt.pfeifle
Details
Screenshot of PDF document on OSX 10.10.4 (120.57 KB, image/png)
2015-08-13 10:01 UTC, Alex Thurgood
Details
Screenshot of LO 5.0.0 UI language/menu settings (112.46 KB, image/png)
2015-08-13 21:24 UTC, kurt.pfeifle
Details
How German UI language settings look if menu item with "Standard" prefix is selected (113.62 KB, image/png)
2015-08-13 21:27 UTC, kurt.pfeifle
Details
Screenshot with LO language settings set to "English (GB)" (311.59 KB, image/jpeg)
2017-11-07 19:52 UTC, kurt.pfeifle
Details
Screenshot with "About LibreOffice" (177.83 KB, image/jpeg)
2017-11-07 19:53 UTC, kurt.pfeifle
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? (15.71 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-11-27 12:52 UTC, kurt.pfeifle
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? (16.11 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-11-27 12:57 UTC, kurt.pfeifle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kurt.pfeifle 2014-02-11 21:57:50 UTC
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.
Comment 1 Owen Genat (retired) 2014-07-18 11:40:55 UTC
(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.
Comment 2 retired 2014-12-26 17:24:14 UTC
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.
Comment 3 QA Administrators 2015-07-18 17:36:42 UTC Comment hidden (obsolete)
Comment 4 kurt.pfeifle 2015-08-01 23:40:24 UTC
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.
Comment 5 kurt.pfeifle 2015-08-01 23:42:40 UTC
(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.
Comment 6 kurt.pfeifle 2015-08-02 00:17:21 UTC
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).
Comment 7 kurt.pfeifle 2015-08-02 00:26:53 UTC
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
Comment 8 Alex Thurgood 2015-08-13 10:01:27 UTC
Created attachment 117882 [details]
Screenshot of PDF document on OSX 10.10.4
Comment 9 Alex Thurgood 2015-08-13 10:02:06 UTC
No repro on OSX 10.10.4 with LO 5.0.0.5 after launching script from Terminal.
Comment 10 Alex Thurgood 2015-08-13 10:04:07 UTC
Problem seems limited to OSX 10.9.5.
Comment 11 kurt.pfeifle 2015-08-13 14:04:43 UTC
(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.
Comment 12 kurt.pfeifle 2015-08-13 14:05:25 UTC
(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?
Comment 13 kurt.pfeifle 2015-08-13 14:21:50 UTC
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?
Comment 14 Maxim Monastirsky 2015-08-13 14:40:25 UTC
(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.
Comment 15 kurt.pfeifle 2015-08-13 14:51:48 UTC
(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?!?
Comment 16 Maxim Monastirsky 2015-08-13 15:06:12 UTC
(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?
Comment 17 Maxim Monastirsky 2015-08-13 15:11:15 UTC
(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.
Comment 18 kurt.pfeifle 2015-08-13 15:54:16 UTC
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.
Comment 19 Maxim Monastirsky 2015-08-13 20:58:38 UTC
(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.)
Comment 20 kurt.pfeifle 2015-08-13 21:21:00 UTC
(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.)
Comment 21 kurt.pfeifle 2015-08-13 21:24:57 UTC
Created attachment 117904 [details]
Screenshot of LO 5.0.0 UI language/menu settings
Comment 22 kurt.pfeifle 2015-08-13 21:27:52 UTC
Created attachment 117905 [details]
How German UI language settings look if menu item with "Standard" prefix is selected
Comment 23 Maxim Monastirsky 2015-08-13 21:54:04 UTC
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.
Comment 24 kurt.pfeifle 2015-08-13 22:34:31 UTC
(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.
Comment 25 Maxim Monastirsky 2015-08-13 22:41:36 UTC
(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.
Comment 26 kurt.pfeifle 2015-08-13 22:52:23 UTC
(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!
Comment 27 Maxim Monastirsky 2015-08-13 23:05:18 UTC
OK, I'm giving up. Have no clue why it doesn't work for you.
Comment 28 kurt.pfeifle 2015-08-13 23:17:20 UTC
(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...
Comment 29 Alex Thurgood 2015-08-14 12:27:53 UTC
How about 

export LC_PAPER=A4
Comment 30 Alex Thurgood 2015-08-14 12:29:32 UTC
Alternatively, you could try installing the en_GB langpack, where the default page size for English should be A4
Comment 31 kurt.pfeifle 2015-08-16 15:17:13 UTC
(In reply to Alex Thurgood from comment #29)
> How about 
> 
> export LC_PAPER=A4

I tried this -- didn't help.
Comment 32 kurt.pfeifle 2015-08-16 15:19:25 UTC
(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.
Comment 33 Alex Thurgood 2015-11-30 08:48:29 UTC
@kurt : any news on recent testing with a GB langpack ?
Comment 34 QA Administrators 2016-05-09 20:08:54 UTC Comment hidden (obsolete)
Comment 35 kurt.pfeifle 2017-10-22 11:07:52 UTC
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...
Comment 36 kurt.pfeifle 2017-10-22 11:51:44 UTC
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.
Comment 37 Alex Thurgood 2017-11-06 08:35:24 UTC
(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 ?
Comment 38 kurt.pfeifle 2017-11-07 19:52:33 UTC
Created attachment 137602 [details]
Screenshot with LO language settings set to "English (GB)"
Comment 39 kurt.pfeifle 2017-11-07 19:53:44 UTC
Created attachment 137603 [details]
Screenshot with "About LibreOffice"
Comment 40 kurt.pfeifle 2017-11-07 19:53:58 UTC
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.
Comment 41 kurt.pfeifle 2017-11-07 19:58:45 UTC
(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...)
Comment 42 Alex Thurgood 2017-11-09 12:30:10 UTC
(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.
Comment 43 Alex Thurgood 2017-11-09 12:44:25 UTC
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
Comment 44 Alex Thurgood 2017-11-09 12:46:59 UTC
(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 ?
Comment 45 kurt.pfeifle 2017-11-27 12:27:46 UTC
(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.
Comment 46 kurt.pfeifle 2017-11-27 12:52:55 UTC
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.
Comment 47 kurt.pfeifle 2017-11-27 12:57:36 UTC
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".
Comment 48 kurt.pfeifle 2017-11-27 14:36:46 UTC
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!
Comment 49 kurt.pfeifle 2017-11-27 14:38:08 UTC
Ah, ugghh... I cannot set a status of "CONFIRMED" for this bug. Oh, well...
Comment 50 kurt.pfeifle 2017-11-27 22:40:26 UTC
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? )