Tracked Changes, PDF/Word, and Branching to Retain Redlines

This forum is for all Flare issues not related to any of the other categories.
Post Reply
Jeff_Lower
Jr. Propeller Head
Posts: 1
Joined: Tue May 10, 2022 9:26 am
Location: Pittsburgh, PA

Tracked Changes, PDF/Word, and Branching to Retain Redlines

Post by Jeff_Lower »

Good morning!

How do other teams retain their redlines in perpetuity when the only way to output a PDF with the changes is to ACCEPT them... which then deletes the changes in the redline? My company works in a highly regulated environment. We must submit redlines to regulatory bodies who then take many months to approve them... whilst other countries' changes have already been approved and need their clean, updated PDFs sent out to printing presses.

Some ideas that we've considered and/or tested have been:
  • Branching: create a branch with the tracked changes unaccepted and leave it untouched while other branches are updated
    PDF Compare: forget about Flare tracking changes and just use Acrobat Pro's Compare function to note differences between two targets (this is odd for our reviewers as they are not used to viewing tracked changes this way)
    PDF Compare + Branching: ignore Flare's tracking changes function and create version branches and then use PDF Compare to capture the changes (see above for reviewer concerns)
    Word Compare + Branching: ignore Flare's tracking changes function and create version branches and then use Word Compare to capture the changes (Word output isn't as accurate visually as a PDF but it shows changes in a familar fashion)
If any propellerhead has any other ideas, I'd love to hear about them. Thanks in advance!

Best,
Jeff
Jeffrey Lower
Sr. Instructional Designer with Dexcom • Illustrator • Nerd • Ice Hockey Player
Pittsburgh, PA
doloremipsum
Sr. Propeller Head
Posts: 290
Joined: Mon Aug 26, 2019 2:11 pm

Re: Tracked Changes, PDF/Word, and Branching to Retain Redli

Post by doloremipsum »

You've listed good options, those are basically what I've come up with in the past when grappling with similar problems. Here are a few thoughts:
  • I think that branching is a good bet if you can get the processes right and everyone on the team understands what you're doing and why. It's a great way to create a baseline and be certain that only specific changes (e.g. revisions from a regulatory body) make it into the content. One problem we have is that we send things off for approval and in the meantime make other changes to shared snippets that flow through to change the document before it's been approved - creating a branch at the start of the process would prevent that (hindsight is wonderful...). It could get complicated though, and potentially difficult to understand.
  • The PDF compare tools I've found are not always ideal because they typically compare the pixels of the PDF, as opposed to the text. That means that something like a new line break or page break could cause a lot of spurious changes. Maybe Acrobat Pro can deal with that better though - I'm limited to free tools.
  • We use Word Compare for "casual" review copies - basically a version of the doc that shows one of our big customers exactly what has changed in an updated document. It generally compares the text well, although it doesn't always display it in a particularly readable way. It does throw up spurious changes on images, presumably because it's trying to compare the pixels and failing to realise that they're the same image.
Anyway, I'd go with branching if you can make it work!
in hoc foro dolorem ipsum amamus, consectimur, adipisci volumus.
Post Reply