Because XpressDox has such a rich set of text manipulation features, it is not only ideal for traditional document assembly, but also for tasks such as generating web pages, XML and even program code.
Prior to version 5 of XpressDox, it has been possible to structure a Word document as if it were text (e.g. the contents of the Word document can look like HTML) but marked up with XpressDox fillpoints. The «SaveAsText()» command can then be used to do just that – i.e. save the merged Word document content as plain text.
It is now possible to take a text file in a normal text editor (like Notepad or Notepad++) and mark that up with XpressDox fillpoints. That text file can then be run just as if it were a Word template, and the merged document will be saved as text (and opened in the native application for the extension that the saved file has).
The way this works is that when XpressDox is given a file to run, it will always attempt to open that template as if it were a .docx/OpenXML format document. If this fails, then XpressDox will open it as plain text and convert it internally to a .docx/OpenXML format and then run that. The conversion mechanism is fairly straightforward – it takes each line (delimited by the “new line” character) and regards that as a paragraph for Word purposes. Knowing this, the text-file-template-author can take into account the XpressDox conventions around paragraph handling. For example, if an If command appears on its own in one line of the text file, then it will not appear in the merged text file. And, a «RemoveParagraph()» will cause the line of the text file in which it appears to be removed from the merged text file.
Currently the XpressDox desktop will accept files with the following extensions as text files which can be run:
.cs, .htm, .html, .rtf, .txt, .vb, .xml, .xsd, .xsl
Care needs to be taken when considering RTF files. XpressDox will handle those files exactly as if they are plain text files (which in most respects they are). In particular, the end of line characters in an RTF file are there purely for human readability, they have no relation to the paragraphs in the Word document that the RTF represents. And yet XpressDox will use them as paragraph delimiters when doing the internal conversion of the RTF text to .docx/OpenXML format before running it. This can have the effect of producing incorrect output RTF if the XpressDox paragraph handling conventions referred to above are not taken correctly into account by the template author.
The other factor to be taken into account when using XpressDox to merge an RTF file is that if the file is created in Word with the fillpoints typed into the Word document and then saved as .rtf, then in all likelihood the text between the fillpoint delimiters will have a fairly large smattering of RTF commands inside it. XpressDox does not know anything about RTF syntax and will try to interpret those RTF commands as normal XpressDox, which they are not. The RTF text will need to be edited in a text editor to eradicate all those RTF commands inside the fillpoints.