Problems with propagating content control/input field content

[mbg_dl]

Hello there.

A little background: I’m trying to create a series of document templates for internal use with a cover sheet containing a number of input fields where the content is then automatically propagated to the header and footer of each page in the document.

I’ve already created a suitable template in MS Word using custom controls and XML mapping to allow easy metadata extraction using our document management system, but since LibreOffice only has rudimentary custom control support and no Word-compatible XML mapping support, the template naturally doesn’t function in LibreOffice properly.

As such, we’ve decided to create a separate LibreOffice template for our LibreOffice users. I’ve managed to implement the free-form text input fields using the legacy input fields/user fields and it works fine, but there are also a number of date and drop-down fields, and these are where I’m having a problem.

(Just a quick mention of the fact that I cannot use macros for policy reasons, and I also cannot use database connections as this template needs to be usable even outside of the network.)

As I see it, there are three ways to implement this:

• Variable fields: Free-form input fields work well in this case as I can simply add user fields with the requisite variables in the headers and footers and then the corresponding input fields in the cover sheet form. However, this functionality fails when trying to implement input fields as the field only accepts text or integer values and thus only accepts a date entered as the number of days relative to the epoch date 1899-12-30. Drop-down menus are apparently not possible here.

• Function fields: Free-form input fields are possible, but I can find no way to create a user field that displays the content of this field. Drop-down lists are possible, but I have the same problem that I can’t find a way to reproduce the selected content elsewhere in the document. Dates don’t seem to be possible using functions.

• Content controls: Free-form, date, and drop-down input fields work perfectly (and are my preferred implementation), but LibreOffice doesn’t seem to provide any documented way to access the inputs in the content controls. In MS Word they would be mapped to a field in a defined XML schema and a second content control elsewhere in the document but mapped to the same field would “pick up” the content via the shared mapping. But because LibreOffice doesn’t support XML mapping of content controls, the fields are basically just there with no apparent or documented way to cross-reference them elsewhere in the file. The documentation suggests that the tag can be used as a machine-readable identifier for external programs, which would be helpful for our document management, but I still need to reference the fields from within the document.

Does anyone know how a consistent, user-friendly form can be implemented using any of these three systems with free-form text, date, and drop-down input support and the ability to propagate field input to other parts of the document? I’d appreciate any ideas that anyone might have. Many thanks in advance!

[ajlittoz]

The problem here is you are asking help on an implementation decision (using form controls) without exposing the full context. You seem to be blinded by the Word existing implementation (no offence intended, it is very difficult to step back when you’re under pressure).

If I understand correctly, your documents have two parts: a “configuration page” to enter document-wide data, such as reviewer name, document id, revision, date, … and the pure-contents part.

You followed the form controls idea based on your knowledge of Word workflow. In Writer, form controls are use for forms, i.e. interactive documents intended to collect end-user data (application form, administrative requests, …). What is entered in fields has no impact on “fixed” text because form fields and text live in different spaces.

In Writer, to create document-wide customisable data, you go through under-estimated “Properties” feature.

Open File>Properties, Custom Properties tab to create new “properties” (you have “standard” properties in the Description tab). Properties can be text, numbers, boolean and, what is of interest to you, date or date-time.

Properties define new fields which can be inserted as Insert>Field>More Fields, DocInformation tab. In Type, Custom is is collapsible list of your custom properties.

The main difference with Word is the definition of your document-wide data is “out-of-band”; it is not mixed with text, so that no precaution is needed when printing.

There is however a limitation: redefinition of a custom property in a document hides properties in the template (assuming you use word template with Writer semantics, i.e. a file with .ott extension containing styles and initial contents). Say, one of the properties is the template revision number and after modifying the template you bump the number. This new revision number will not be reflected is the templated document because the property “dictionary” is considered user contents. Consequently, to avoid data loss, it is never (automatically) updated when the template changes.

Please mention OS name, LO version and save format. The latter is very important. If the goal is to produce .doc(x) documents, I am afraid that what I described won’t work (or persist across edit sessions).

[mbg_dl]

Hi there, thanks for answering.

Please mention OS name, LO version and save format. The latter is very important. If the goal is to produce .doc(x) documents, I am afraid that what I described won’t work (or persist across edit sessions).

I’m working under Win11 with LO 24.8.2.1 and exclusively .odt/.ott files. That said, the template will be used by users under a variety of OSs. The .docx/.dotx file (of course, I use .docx and .odt as my WIP versions) is the functional model for a functional “clone” I’m producing in LO as, unsurprisingly, the .dotx file isn’t fully compatible with LO. This is to maintain a strict separation of .dotx and .ott documents - the .ott template will be used exclusively by LibreOffice users, but it does need to offer the same essential functions as the .dotx template.

If I understand correctly, your documents have two parts: a “configuration page” to enter document-wide data, such as reviewer name, document id, revision, date, … and the pure-contents part.

Your understanding is correct. In our Word template, the text fields displayed in the headers and footers of each page mirrors the form inputs on the cover sheet. Those text fields are also nothing more than form content controls, only set to be read-only.

In Writer, to create document-wide customisable data, you go through under-estimated “Properties” feature.

Incidentally, the initial plan for the Word template to have these document properties stored as custom document properties in the same way as you describe (as is the norm), but that plan was rejected when it transpired that macros would be needed to modify the properties via the cover sheet form.

Instead, I’ve leveraged the XML mapping feature in Word whereby field contents can be mapped to either fields in the Microsoft Open XML schema or to a custom XML schema, whereby all fields in our case are mapped to a custom schema for simplicity and tidiness: it allows the DMS to extract a single, tiny XML file from the docx file as a ZIP archive and pull everything it needs from it.

Metadata extraction is not a problem in LibreOffice, as I can extract the field data from the <loext> tags in the content.xml file of the ODT archive - perhaps less tidy, but still doable.

Where the implementation fails in LO is that, while Word allows content controls to reference and modify one another through XML mappings, LO does not. The form inputs are stored in content.xml, but cannot be referenced by other content controls or fields in the same document - at least to my knowledge.

The only way I’ve managed to achieve something functionally similar in LO is through variable input fields and user fields, but this is only possible with integers and freeform text and doesn’t allow date or drop-down inputs.

The form content control implementation in LO provides date and drop-down inputs, but doesn’t allow content controls to reference one another.

If push comes to shove, I can have the date and drop-down inputs as free-form inputs, but it would be preferable to have drop-down and date selectors as the fields in order to keep the formats and inputs limited to specified formats and permitted values.

Properties define new fields which can be inserted as Insert>Field>More Fields, DocInformation tab. In Type, Custom is is collapsible list of your custom properties.

As I understand it though, there is no way to modify document properties (custom or otherwise) with the use of input fields or content controls.

[ajlittoz]

@mbg_dl

As I understand it though, there is no way to modify document properties (custom or otherwise) with the use of input fields or content controls.

Exactly.

Form controls are intended for to-be-filled forms where control contents is the “end product”. Eventually, when such a document is coupled with Base, you consider it as an entry medium for DB interaction but in this case, I prefer separate development with ad hoc tools.

Variables are fine for variable data across the document , i.e. some data you will change here and there and have it echoed in text. It is quite tricky to prevent the value-change locations from being seen and simultaneously have them clearly identified. Note that I met difficulties when the mirror is in header or footer because the header or footer seems to be calculated on first encounter and cached for future use (subsequent pages). As you have noticed, variable contents is limited because you can combine them in expressions to build sophisticated conditions.

Personally, I have not completely understood what input field variables are. Therefore I don’t use them (as the properties fit my needs).

Properties are yet another domain. They are created in the File>Properties dialog. Since it is external to text, you can’t use text contents (be it fields, variables or form controls) to initialise them. Consider they are instantiated well before text. This naive representation explains why there can’t be interaction in this direction (text to properties) while the opposite is possible (properties to text).

It is likely that macros can modify them. But I never wrote any LO macro preferring to always create “static” documents.

The Writer philosophy here is to separate property setting from the document contents itself. If your requirement is to keep the “configuration cover page”, you’ll indeed need macros to transfer variable values to properties. Allow me to consider this is wrong: you (or your hierarchy) try to impose an alien (Word) model on a different tool (Writer). I know that practising Writer approach would result in a change of procedure for your users but adopting another tool always requires an adaptation of procedures otherwise the new path is doomed to fail (I experienced several expensive failures of this kind).

What remains mysterious for me is the extraction step to create a small XML file, probably because I don’t know what is the Word XML mapping. I tend to be very suspicious when somebody wants to transform the ODF XML. It then becomes very easy to mess up the encoding in such a way that Writer can no longer manage correctly the document (information loss). Of course, if the XML excerpt has another purpose, external to Writer, my remark is not relevant.