Document assembly

[Vanceone]

Greetings all,

I have suddenly been given a bunch of work where I essentially have to create a standard template document and change it for each client. This involves a bunch of fill in the blank stuff, like "Contract cost" and the like.

This would be simple enough as a merge document, but unfortunately I need a bit more decision making than I think a merge document can handle. Things like gender specific references: "His" versus "Her", and some conditional clauses where I can programmatically insert or not extra lines in a list, or possible paragraphs, depending on the answers given. In short, some document assembly. Software for this exists on the PC side, like HotDocs, and has for decades (indeed, I actually took a college class from the designer of HotDocs). So far, however, I have not seen anything like this for the Mac.

I saw Philips thread on the merge command here: https://nisus.com/forum/viewtopic.php?t=6041, but I am not sure that this approach is the correct. It's almost like I need an HTML style template, with a programming language built in like a PHP template would be. Of course, I am sure Nisus' macro language should be able to do the job. Or would it be better to build a template assembler in a scripting language, then dump the finished template into Nisus? I don't know how to handle attributed text that way, and using Nisus' automatic styles and numbering seems much easier than having to track all of that in, say, python.

Any ideas?

[phspaelti]

I'm pretty sure you could handle the cases you mention ("his/her", optional paragraph) using mail merge. But that doesn’t mean I would recommend it. You could also do any of the following:

1. Create your own "mail merge". Create the default document with the replaceable fields marked with a special character style. Put the data into a table in data document, and then write a macro that would transfer the necessary bits. The main advantage of this over mail merge is that the macro language would allow you to write more complex decision making.
2. You could dispense with the default document, and instead use the macro to create the document from the data directly. Put the reusable parts into variables in the macro, and add them as necessary.

[adryan]

G'day, all

A brief note on automating gender changes might not go astray here.

A problem arises because of ambiguity regarding the words "his" and "her". The same word could represent a possessive adjective or a possessive noun, and both parts of speech could occur in the same document.

The feminine analog of "his" could be "her" (adjective) or "hers" (noun), while the male analog of "her" could be "his" (adjective) or "him" (noun). So it is apparent that one can't blindly replace all the occurrences of these words with the one variant relating to the other gender.

In the absence of some sort of grammar checker, or perhaps an AppleScript script that somehow uses a dictionary lookup to determine the part of speech of the word immediately following one of the above possessive pronouns, one should incorporate in one's template document placeholders that take cognizance of these distinct parts of speech when using the Merge mechanism.

Cheers,
Adrian

[phspaelti]

This isn't really an issue for mail merge. Generally you would have a form letter and in the context of the sentence you had written you would know if you wanted the genitive (a choice between his/her or his/hers) or you wanted the accusative/dative (a choice between him/her). So no grammar checking needed.

Example:
Dear <title> <parent-name>, we regret to inform you that your <son/daughter> <child-name> has not been completing <his/her> assignments on time and has been taking items from others that are not <his/hers>. Please see to it that <he/she> gets appropriate help or we may be forced to expel <him/her>.
Best regards.

So a single gender variable could be used to set all variables in this text to the appropriate choice, though of course more modern systems might require more than just binary choices.

[adryan]

G'day, Philip et al

My cautionary remarks were meant to cover all automated gender changes, not just those using the Merge mechanism. The grammatical nuances will have to be considered at some stage, as indeed you have done in your choice of placeholders in your example document.

Merge has other uses besides mail-merging. It's not clear whether Vance has letters in mind, for instance. Furthermore, placeholders may not have been inserted at the time of document creation and need to be inserted at some later date. (In fact, the NWP User Guide suggests this may often be the preferred procedure.) And a document may be quite lengthy, with numerous instances of these pesky pronouns, so there would be a natural temptation to use Replace All in some way. One example might be a stage play where character names and sex may need alteration for some special purpose.

All I'm saying is that one needs to be ever careful what one is replacing with what. And prudence dictates that, for each possible option chosen from a set of problematic ones (such as the possessives we've been discussing), one peruse a representative final document to ensure (to continue the theme) who's doing what to whom with whose is as it should be.

With respect to Vance's original problem, without knowing the workflow and the precise format of the items involved it's difficult to know how best to proceed. But I'd probably be inclined in the first instance to use the Merge system and supplement it with a Nisus Macro as needed. You might need to be a bit creative with the merge source records file. For example, one field in each record may actually be the value of a placeholder that is situated at the end of the template document. Subsequent running of the Macro would poll this value, perform operations accordingly and finally delete the value of the placeholder from the end of the document.

Cheers,
Adrian