Bug 124021 - PDF export of spreadsheet forms change fields positions in page
Summary: PDF export of spreadsheet forms change fields positions in page
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: filter:pdf
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
Reported: 2019-03-12 11:39 UTC by Olivier Hallot
Modified: 2021-02-14 04:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Source file with fields in right position (660.67 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-03-12 11:39 UTC, Olivier Hallot
Produced PDF file with fields in worng position (229.53 KB, application/pdf)
2019-03-12 11:40 UTC, Olivier Hallot

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2019-03-12 11:39:41 UTC
Created attachment 149910 [details]
Source file with fields in right position

The attached spreadsheet form display fields correctly positioned and *all* fields (text box, radio buttons, list box) are anchored in cell and their size were set "adjust size to cell size" (or the like in English), using context menu on selected fields.

Symptom: On exporting to PDF form, the fields are shifted to wrong position, often overlapped and makes PDF form unusable. 

Some hints:
* The effect seems random. Sometimes it works, sometimes it produces a messy PDF.
* it seems to depend on saving and reopening the file
* on adding or removing lines/columns/cells, 
* perhaps on cell position recalculation in page, with effect on anchoring. 
* On cell rendering, the field anchoring changes, seems to shift to a neighbor cell
* field size does not follow cell size.
* suspicion on rounding number for cell position and field position calculation.
* suspicion on memory leak or uninitialized variable.

Affects LibreOffice 6.1.5 and later, not tested with earlier versions.

Tested on Linux (6.2.1 and okular) and Windows (LO 6.1.5, with display in Acrobat Reader DC)
Comment 1 Olivier Hallot 2019-03-12 11:40:23 UTC
Created attachment 149911 [details]
Produced PDF file with fields in worng position
Comment 2 Olivier Hallot 2019-03-12 11:45:16 UTC
Some further information:

* On exporting each sheet in one PDF document (1 sheet per page), the fields are not shifted.

* After opening the form, it seems that the page rendering is introducing small offsets in cell position and often the anchor jumps to a neighbor cell.
Comment 3 V Stuart Foote 2019-03-12 14:14:52 UTC
Does setting "Use printer metrics for text formatting" (Tools -> Options -> LibreOffice Calc ->  General: Input settings checkboxes) and tweaking the fielded sheet help to hold positions on export to PDF?

Working the test document, I see cells shift within Calc when setting unsetting the use printer metric value. But the PDF export is consistent with/without. 

Don't know if that is full extent of the layout changes you see, but may be contributing. And of course we can't leave the printer metrics enabled all the time as it kills sheet performance.
Comment 4 Olivier Hallot 2019-03-12 18:18:11 UTC
Another hint that help to overcome the issue:

1) Open the spreadsheet form, 
2) do all editions, set all fields positions.
3) *save file*
4) *close file*
5) Open file
6) export to PDF. *Do not edit file before exporting to PDF*
Comment 5 Buovjaga 2019-08-03 17:43:37 UTC
I could not reproduce. Made a test by inserting a row, exporting to PDF.

Arch Linux 64-bit
Build ID: 4bd1b38633d6cb288eb559afc0ac6b961538ae60
CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 24 July 2019
Comment 6 Xisco Faulí 2020-07-17 10:59:09 UTC
Hello Olivier Hallot,
Is this issue still reproducible with the latest version of LibreOffice from
https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 7 QA Administrators 2021-01-14 04:07:14 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2021-02-14 04:05:21 UTC
Dear Olivier Hallot,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA 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