We're sorry GroupDocs doesn't work properply without JavaScript enabled.

Free Support Forum - groupdocs.com

Date field in template populated as plain text

Hi,
we found that the date field is populated as a plain text in template “Template_GeneratedByGroupDocs.doc”(one attached here) instead of driven by formula.
we can view the formula for the date field in template “Template.doc”(one attached here)in by selecting the field, right click and select the option “Toggle Field Codes”.

Following files are attached for your reference:
1)Template.doc - Input file used to test the GroupDocEditor.
2)Template_GeneratedByGroupDocs.doc - Template generated by GroupDocsEditor.

Regards,
Ayyappan

Templates.zip (32.9 KB)

@ayyappanprofile

This scenario is under investigation. Your investigation ticket ID is EDITORNET-2330.

@ayyappanprofile

We reproduced these steps and our resultant document is the same as your “Template_GeneratedByGroupDocs.doc”.

What you described is expected and programmed behavior for the GroupDocs.Editor at this moment. In the original document all of these data fields, driven by formulas, are internally implemented by the so-called “fields” (list of field codes). We’ve inspected the original document and most of fields are MERGEFIELD and IF fields. They may be treated as the tiny coroutines in the WordProcesing document, like macros in MS Excel. And the problem is that when we convert document to the HTML/CSS (represented by EditableDocument instance), we can preserve only appearance, but not the behavior. Fields mean some action or behavior, and in order to translate this to some other format (HTML in our case) you should be able to store the “programming routine”. But HTML/CSS are markup and spreadsheet languages, not the programming languages.

Theoretically it is possible to preserve field codes by using a JavaScript. But in this case we will lose one of our biggest advantages — compatibility with any possible WYSIWYG-editor. When emitting not only the HTML/CSS, but also JavaScript, we become dependent on the specific WYSIWYG-editor, where the document content is loaded and edited.

So, concluding: at this moment fields are transformed to the plain text when saving document to the HTML/CSS. And when you convert document back to the DOC format, they are absent.

However, we can suggest you one option. If you do not require fully functional field in the intermediate HTML/CSS, but require them as fields, not as plain text, in the output/resultant DOC(X), we can make the next approach: when forward-converting to HTML/CSS, we store something like little hidden breadcrumbs in the HTML-markup (for example, some custom “aw-*”-prefixed HTML attributes), which encode original fields in the exact locations where they are present in the original document. In the WYSIWYG-editor, where you edit the document content, these breadcrumbs are hidden. But when edited HTML-content will be obtained by the GroupDocs.Editor for the backward conversion, the backward converter will detect these breadcrumbs and restore the original fields not as a plain text, but as fully-functional fields.

If such approach is viable for you, please let us know, which field codes are the most important for you, so we implement their preserving and restoring in the resultant DOC(X).

Hi Tahir,
Thanks for the information. We are looking into this and will get back to you shortly.

Regards,
Ayyappan

@ayyappanprofile

You are welcome.

Hi Tahir,
Thank you for the suggestions. We have now managed to find a workaround, and therefore this bug can be closed. It may still be a product feature you would like to investigate further for the next improvement. But we are ok with this one. Thanks again.

Regards,
Ayyappan

1 Like

@ayyappanprofile

Glad to know that the issue is resolved.