Bug 105972 - PDF form export does not save field types
Summary: PDF form export does not save field types
Status: NEW
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
: 126031 (view as bug list)
Depends on:
Blocks: PDF-Export Form-Controls
  Show dependency treegraph
Reported: 2017-02-13 02:47 UTC by Christopher Smith
Modified: 2021-08-10 18:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

sample form as ODT with text, numeric, and date fields (10.95 KB, application/vnd.oasis.opendocument.text)
2017-02-13 02:47 UTC, Christopher Smith
that form rendered as a PDF/FDF form with default options (26.53 KB, application/pdf)
2017-02-13 02:48 UTC, Christopher Smith

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Smith 2017-02-13 02:47:51 UTC
Created attachment 131163 [details]
sample form as ODT with text, numeric, and date fields

I am exporting a LibreOffice form as FDF. On export, all fields (or at least numeric and date fields) are saved as plain text fields with no format restrictions. I first observed this behavior in 5.1; it is still present in
Comment 1 Christopher Smith 2017-02-13 02:48:58 UTC
Created attachment 131164 [details]
that form rendered as a PDF/FDF form with default options

Note that the fields that should be tagged as numeric or date are instead set as plain text.
Comment 2 Buovjaga 2017-02-14 12:06:51 UTC
Did or work in a version older than 5.1? I don't have Adobe Acrobat on this machine, so cannot test, have to try on another one later.
Comment 3 Christopher Smith 2017-02-14 15:10:00 UTC
I had not tried to export PDF forms in a version older than 5.1.
Comment 4 Buovjaga 2017-02-17 14:45:57 UTC
Confirmed with A. Reader XI.

Win 8.1 32-bit
LibO Version:
Build ID: 9077f1f110a35ed223fb47e9eaa329dd19528e38
CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-16_23:34:39
Locale: fi-FI (fi_FI); Calc: group
Comment 5 QA Administrators 2018-02-18 03:38:30 UTC Comment hidden (obsolete)
Comment 6 Roman Kuznetsov 2018-12-10 07:22:15 UTC

ID сборки: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
Потоков ЦП: 4; ОС:Windows 6.1; Отрисовка ИП: по умолчанию; VCL: win; 
Локаль: ru-RU (ru_RU); UI-Language: ru-RU
Calc: threaded
Comment 7 Dieter 2019-06-22 11:49:24 UTC
Still repro in

Version: (x64)
Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded
Comment 8 Dieter 2019-06-22 11:50:36 UTC
*** Bug 126031 has been marked as a duplicate of this bug. ***
Comment 9 QA Administrators 2021-06-22 03:37:22 UTC Comment hidden (obsolete)
Comment 10 Christophe Strobbe 2021-08-10 18:10:20 UTC
I have verified this bug in two versions of LibreOffice and can confirm that it is still present.
I have tested it both in LibreOffice on OpenSUSE Leap 15.2 and
in LibreOffice on Windows 10.

After exporting the form on OpenSUSE and opening the PDF file in Okular, both the numeric field and the date field accept any sort of Latin characters (and also Chinese characters that I pasted into the form fields).

After exporting the form on Windows 10, I checked the form in Adobe Acrobat Pro DC and check the form field properties: each field accepted any sort of string; a number format or a date format were not defined. (For the numeric field, the min and max values that define the range of numbers were obviously also gone.) Adding the input format again in Adobe Acrobat is easy to do, but this software product is not available for Linux.