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

[Enquire]

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.
.
Any thoughts?
~~
LO Duplicate field names - test 01.odt (13.4 KB)
LO Duplicate field names - test 01.pdf (20.4 KB)

[Ash733]

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.

[Enquire]

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!

[Ash733]

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.

[Enquire]

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?!?
~~

[Ash733]

@Enquire

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.

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

@Enquire

However, in Writer they act independently, as if they had different field names.

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

@Enquire

So, why does Writer (from which the PDF was exported) not do this?!?

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/

[Enquire]

“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?
~~

[Ash733]

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/).

[mikekaganski]

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

[Wanderer]

@Enquire

So, why does the source LO Writer. odt document NOT behave in the same manner as the exported PDF?

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.

How to repeat field in LO Draw elsewhere when making a PDF flat form fillable?

I guess you use Draw, because pdf is usually opened there, when you open a pdf with LibreOffice? Most other questions came from users of Writer… . LO was not designed as a PDF-Editor. The tool you see/use are the same for users of the database-tool named Base. A form in Base is actually a Writer-document with special properties… There the connection to the datasource is managed on the “data” tab you may see in the picture posted by @Grantler above. You can set the same field for more than …

[Enquire]

1. I did, previously, attempt to use LO Draw to make an existing form fillable, but soon realized that this was tedious and did not provide the functionality that I was seeking — so the referenced thread is an old thread that I have since abandoned.
2. I next created a form in msWord that did what I wanted — it was fillable and identically named fields were synchronized as expected. However, when I exported the form to PDF, it ended-up as a flat document — in other words the fields were not fillable as they were in msWord for whatever reason.
3. So, I returned to LibreOffice. I started-over creating a form in LO Writer and added fields — some of which I gave the same field [Name} because were repeated in multiple places in the document. This sort of worked — except that the identically named fields behaved independently. Filling in one instance did not update the other identically named form fields. Also, it was possible to fill-in different names in each instance. However, when I exported the document to PDF, the fields still worked (unlike exporting PDF from a msWord document). And, if I checked the box during export to allow duplicate fields - the exported PDF worked exactly as needed and expected.
   .
   In conclusion, LO Writer can do something that msWord cannot - in other words create a fillable form that works both as a fillable form in LO Writer AS WELL AS an exported PDF fillable form (if “allow duplicated fields is checked” during export to PDF) — with the caveat that duplicated fields in LO Writer itself behave as independent fields - not as (linked and synchronized) duplicate fields.
   .
   As such, LO Writer appears to be a good fillable form creator that supports duplicate fields (which share same name) — so long as it is exported to PDF fillable form.
   ~~