(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.

(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.

(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!

(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 ?

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.

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.