The two main things that we need out of the tool that does this is to have it format financial tables in specific ways for our industry and to produce a kind of revision marking called "blacklining" that is the industry standard.
The macros to do the table formatting work pretty spiffly, much better than the similar ones used in our current HTML tool.
The blacklining, however, is becoming a problem. Word has decent revision marking for things that aren't too complex but we're dealing with files that often have many revisions across many cycles of proofs.
Since we occasionally have to produce proofs that show all the changes made to a document from it's initial state to its current state (called "cumulative" proofs), the decision was made to store all the revisions in Word, marking them as being made by separate reviewers named by the cycle number. The problem with this is that, when we create proofs for proofreading and most deliveries to our customers we want to show only the changes made in the current cycle (called "precise" proofs). So, currently, the macros create a PDF file that shows a cumulative proof and then we filter that PDF to create the precise proof. Nice enough for the first few cycles, but as more and more complex edits are made, the process of creating that cumulative proof really slows down.
Today, I suggested to the programmer manager (who is conveniently sitting with us on third shift this week) that, rather than filter for the precise proof at the PDF, that we do it before we create the PDF. That is, have Word temporarily hide or delete the edits made on previous cycles and then create the precise proof PDF. If a cumulative one is needed (a rare occurance), we could take the time to do it, or offload it to another machine or server, freeing up valuable desktop time for important activities (like keeping up with LJ! ;).
He said "Good idea!" and will talk to the programming team about it. We'll see if this helps make things easier in the sort term.