How to repeat a fillable field in LO Writer that still works when exported to PDF

I am creating a fillable form in LibreOffice Draw. (I previously discovered that forms created in Microsoft Word do not export as live forms. Forms created in Word export as a flat file - in other words, the form fields appear, but cannot be edited.)
.
In LibreOffice, it seems that forms created in LO can be exported to PDF and still act as fillable forms (as expected). The problem seems to be that repeated fields in LibreOffice Writer appear to act as independent fields - even if they have the same field [Name].
.
However, this problem is miraculously fixed when exported to PDF if check marks against both [Create PDF form] AND [Allow duplicate field names] are checked in the PDF Export Options dialog box. See:

  • LO Duplicate field names - test 01.odt
  • LO Duplicate field names - test 01.pdf

.
In this test form I have three fields (name, address & date) - repeated immediately below. However, although the fields above and below have the same field “names” (Name, Address, and Date) - they behave as though they had different names - i.e. as independent variables. Nonetheless, the exported PDF acts as expected and as intended.
.
Incidentally, for the first one I added BOTH pull down and spin. I assumed that spin would allow skipping from one day to the next, but I was surprised to see that it skipped from one year to the next. This is actually great! I am massively frustrated when asked to fill in my birth date and my finger almost goes numb clicking back from current month until I finally reach my year of birth (epic GUI design failure!).
.
In retrospect, in terms of GUI design the field [Properties Date Field] layout is unwieldly - why are related controls not grouped in some logical fashion. For example, why is [Spin Button] NOT grouped with [Dropdown]?!? And, is there an option to simply type the date (subject to format restrictions)? In any event, the [Properties Date Field] is a little verbose - when for most users they only care about a few variables?
.
Anyway, I would appreciate understanding why the LO Writer test form does not behave as expected - even though the exported PDF does work exactly as expected. :thinking:
.
Any thoughts? :upside_down_face:
~~
LO Duplicate field names - test 01.odt (13.4 KB)
LO Duplicate field names - test 01.pdf (20.4 KB)

Interesting, however can you provide a TLDR as I can’t quite work out what your actual question is despite reading the whole thing 3 times.

Take a look at the .odt and the exported .pdf file. In the .odt document, the fields can be edited independently (the other, duplicate, field does not change). However, in the exported pdf document, if you change one instance of name, address or date - then the duplicate field is also updated. Check it out!

This would be expected behavior in my opinion. PDF’s rely on unique fields to store data, by overriding the option you’re effectively agreeing that you accept this.

I am not quite sure what you suggest that I am “effectively agreeing to accept.”
.
Both instances of name, address and date have the same field name (duplicate fields) - so I would expect that they should be the same, duplicate, data. So, if you change one, then the other instance should change likewise. In other words, it should not be possible for a duplicate field name to have a different value.
.
However, in Writer they act independently, as if they had different field names.
.
Yet, when I export the Writer document to PDF, it works as expected, as intended - edit one instance - and the other instance changes to match.
,
So, why does Writer (from which the PDF was exported) not do this?!?
~~

These options relate to the exported PDF, not the open document.

Yes, because it’s acting like a ODT document and not an exported PDF. The settings above haven’t been applied yet.

Possibly because this functionality hadn’t been considered. If you think it’s a worthy feature you can suggest it here: https://bugs.documentfoundation.org/

1 Like

“Possibly because this functionality hadn’t been considered.”

Seriously?
.
So, let’s use a common use case. Fred Blogs and John Doe enter into a legal agreement. They use an agreement template that, with minor editing is acceptable to Fred and Joe.
.
So, rather than “Party A” and “Party B” they replace each instance of “Party A” with a form field named [Party A] and “Party B” with a form field names [Party B]. In this way, they can enter “Fred Blogs” in any instance of the form field [Party A] and “John Doe” in any instance of form field [Party B].
.
Instantly, the names “Fred Blogs” and “John Doe” magically appear in all the appropriate places in the 12 page agreement. At least, that is what expected to happens.
.
As is now, LO Writer does not prodice that behaviour - even though the PDF produced by exporting from LO Writer does.
.
So, why does the source LO Writer. odt document NOT behave in the same manner as the exported PDF?
~~

I and others here are not LibreOffice developers, if you want a definitive answer you’ll have to ask them yourself by submitting a feature request/bug report (https://bugs.documentfoundation.org/).

There may be perfectly good reasons for it being the way it is, or like I said it may not have been considered or raised by anyone to date. If it is important to you, then ask for it in the appropriate place (https://bugs.documentfoundation.org/).

Note also, that an expectation that since application A behaves like that when uses its file type X, then application B must do the same with its file type Y, is wrong. In LibreOffice forms, the IDs are not used to link the data. Writer doesn’t make the fields linked - it simply sets IDs in the exported PDF, and lets readers to behave as they are designed to do. It’s what PDF readers do: linking the fields because they use the same IDs (maybe because the PDF standard defines that behavior, but that’s orthogonal).

1 Like

I tried to explain in your previous thread: Writers form are usable as forms for Connections to databases, so your “common use case” is only one little side-effect and nice to have, but Open/LibreOffice fill their fields in forms vie the named reference in the data-tab, which you could glimpse in the other threads picture.