I'm forwarding a copy directly to you. Note, however, that that particular post dealt only with the issue of soft hyphens. When proofing a text having line ending punctuation is useful; when reading a text having line ending punctuation in place can be distracting, at best. That post was a proposal of a single method that might be used to reconcile these two competing interests.
This method is only interesting if you are pursuing a single-source solution; if you're planning on using a single master file that /MUST/ be transformed before use there are probably better solutions.
At this point I'm interested in collecting options that people are willing enough to defend with test cases, more than disqualifying any, based on single attributes. Obviously a single master file that doesn't need to be transformed is better than one that does, everything else being equal. OTOH, if you need to generate five alternative formats from one, six isn't that much more.
But it hinges on the proofers. My first inclination is that there is an inverse relationship between proofer adoption and complexity, and between proofer adoption and similarity to "match the image". But I'm willing to be dissuaded by actual testing. I believe that vandenburg from wikimedia had a post in that series about how they were asking proofers to use a moderately complex final format. Do you see that nearby where you found yours? You may remember that I found a post on their site about how they were redesigning the UI for their editor from scratch because they considered that function the most important inhibitor to growth for them. Don't know if I believe it, but they aren't any more likely to be stupid people than we are. Don