Before Word 2002, it was possible to set revision-tracking colors and formatting separately for inserted and deleted text. The procedure was simple:
1. Click Tools / Track Changes / Highlight Changes / Options.
2. Select "Mark" (bold, italic, underline, or double underline) for "Inserted text."
3. Select "Color" (various) for "Inserted text."
4. Select "Mark" (bold, italic, underline, or double underline) for "Deleted text."
5. Select "Color" (various) for "Deleted text."
6. Click the "OK" button.
In Word 2002, however, this feature works only for "Inserted Text." "Deleted text" automatically follows suit, and there seems to be no way to set the two independently. To make matters worse, Strikethrough is no longer among the listed marking options. How annoying! Fortunately, there's a hidden way to overcome these limitations. I've exploited it in the following macro, which you can easily modify to meet your own needs:
Sub SetTrackingFormat()
With Options
.InsertedTextMark = wdInsertedTextMarkUnderline
.InsertedTextColor = wdBlue
.DeletedTextMark = wdDeletedTextMarkStrikeThrough
.DeletedTextColor = wdRed
End With
End Sub
If you don't know how to use macros like that one, you can learn how here.
The macro is currently set to mark insertions as blue text with underline, and to mark deletions as red text with strikethrough. To change this, replace the "Underline" on the end of "wdInsertedTextMarkUnderline" or the "StrikeThrough" on the end of "wdDeletedTextMarkStrikeThrough" with any of the following:
Bold
ColorOnly
DoubleUnderline
Italic
None
StrikeThrough
Underline
Then replace "wdBlue" or "wdRed" with any of the following:
wdBlack
wdBlue
wdBrightGreen
wdByAuthor
wdDarkBlue
wdDarkRed
wdDarkYellow
wdGray25
wdGray50
wdGreen
wdNoHighlight
wdPink
wdRed
wdTeal
wdTurquoise
wdViolet
wdWhite
wdYellow
Then run the macro (Tools / Macro / Macros). Hah, hah! Once again Microsoft Word must bend to your will!
_________________________________________
READERS WRITE
Readers have sent so many great tips and comments that it's taking a while to go through them all. They'll be appearing in the newsletter over the next few weeks. Today's issue makes a good start, however. Many thanks to Bill Rubidge, Rohn Solecki, and Rebecca Evans for their terrific comments and tips.
Referring to the December 18, 2002, issue of Editorium Update, which featured styles and style lists from readers, Bill Rubidge (wbr@aya.yale.edu) wrote:
Eric Fletcher explains that he uses an "Editorial Note" style. We use something similar, but the style is called "Open Issue". (Actually, the name has a prefix, so that all the styles we use are sorted together in the list and distinguishable from styles that may come from other templates or users). The style highlights items with color, as Eric's does, but we do one thing more.
At the end of our documents, we insert a page break and then type a title "Open Issues". Below that, we generate a TOC based only the Open Issue style (not any headings--TOC field {TOC t "wbrOpenIssue,1"}). This gives us a complete list of these open issues for the entire document, to ensure that none are overlooked.
By the way, we also insert these Open Issue paragraphs (which are sometimes just queries) ABOVE the item in question, and the Open Issue style has the paragraph set to "keep with next". This helps make the page number refs in the Open Issue TOC more accurate.
If you really want to get complicated, on multi-file projects (we deal with about 40 files per book), it may be easier to just extract the open issues from the file and put them into another document. For now, I just do this using the open issue TOC at the end of each file, but have a macro that copies it (fields unlinked) to the clipboard and then opens up our Open Issue file (in Excel, for easier sorting). Based on posts in the Word PC listserve, I think involving Maggie Seneca, I think you could also harvest all the Open Issue items in the file and automatically write them to another file (rather than the manual paste we're using).
You might refer to the macro that Bryan and Pieter helped Eve Golden with, back in the Daily Word Tips list. I think the last posts about it were from November 20. That macro searches for text highlighted in a certain way, and copies all that text and appends it to a separate file.
_______________
Rohn Solecki wrote:
I also have a favorite style you might want to pass on. Although it may not be useful to the publishing industry, it is handy for internal documentation in companies that still use "green screen" computer terminals. Green screen terminals are the old style fixed pitch font, by default 24 line by 80 character displays (but optionally up to 27 lines by 132 characters).
Rather than doing a graphic screen capture I do a Edit / Select All, Edit / Copy to capture the text, paste to Word, then apply my "Screen Print" paragraph style to reasonably simulate the appearance of text on the computer terminal. This style has 3 main advantages over pasting a graphic screen capture:
* It uses orders of magnitude less space, which is important if you have lots of screens to capture.
* It is editable, so if something on screen changes you don't have redo the capture.
* Since it is editable, it is easy to apply character formatting like highlighter or font colors to highlight specific sections (without having to use a separate graphics program).
Details of Screen Print Paragraph Style:
* Paragraph Formatting - Flush Left, Keep with Next, Keep lines together, Border: box (single line), Shading: 5%, Indent: Hanging 0.25 Right 0", Widow and Orphan Control. Font Formatting - Courier, 10 pt, Condensed 0.5 pt.
Reasons for choices:
* The Box Border and 5% Shading simulate the look of the screen.
* Keep Lines together and Keep with next ensure that the whole screen capture stays on same page.
* Hanging indent is optional if a line wraps for some reason, for example, capturing from a 132-character display.
* Courier is fixed pitch so characters line up as they did on screen.
* 10 pt Condensed 0.5pt so that an 80-character line will fit on a page with reasonable margins (less than the default 1.5" both sides) without wrapping.
_______________
Rebecca Evans (evansreb@earthlink.net) wrote:
I have been designing and typesetting books for a living since 1976. Being able to use style tags in today's programs is certainly a blessing compared to keeping a spec sheet beside you so you can hand key specs as you re-type a book from a typemarked manuscript.
My comment on the style naming issue is that I have found I do not need list tags that add space after the list (NL End), just the tag to begin the list and for the interior paragraphs. All I need after lists, boxes, and the like, are two Body Text tags with added space above them, one with a paragraph indent and one without, because any paragraph style other than Body Text--heads, extracts, boxes, summaries, other lists--already includes space above.
Of course this assumes that spacing is consistent within a design so that you don't have +12' below a BL and +6' below an NL. And, I realize this may not be applicable to documents other than books. However, in my experience with textbooks, I have found those two extra Body Text styles to be all the "exit" styles I need.
On another note, I use two character style names because that lets me reduce the width of the style tag window (I use Ventura Publisher and keep the style list docked and open on screen), leaving more screen width to display page spreads. This is not an issue if you use a style drop down menu but I thought I'd throw in my two cents on that one too.
I responded, "Not being a Ventura user myself, I'd like to know why Ventura users want to tag Word files before bringing them into Ventura. Won't Ventura import RTF files? Any light you could shed on that subject for me?"
Rebecca replied:
Ventura does import RTF files--it will even File:Open RTF files and build copies of all the Styles as closely as possible to how they are in Word. Irrespective of that, you elucidated the reasons for using raw codes very well in your recent essay.
Most books are Styled erratically by the author and there is usually so much junk left in text files that it's easier to clean up the text if you can see the raw codes. Much of what I clean up is taken care of by EKTPlus but I still like to see exactly what I'm importing before I import it.
Also, an author's Styles, even if perfectly applied, never match the design of the typeset book. It is far easier for me to type codes than to drop down the Style list and click each one. Assign Styles to buttons takes a long time and would be almost as much work to use as dropping down the style list.
I use XyWrite for coding text files because I can drop in coding with short-cut keys, which are incredibly easy to assign in XyWrite: no menus, just select the text, press F2, press the key you want to use for that shortcut (any key), then press F3 to deselect the text. Then it's just ALT+"that key" to insert the text. You can keep reassigning new text to your shortcut keys as you work.
XyWrite also has macro-scripting capabilities that let me build S&R tables for almost anything. I keep the S&R table open in a separate window while I work so I can change/add entries in it as I go along.
Unfortunately, XyWrite is ASCII and everything else in the world (seemingly) is ANSI so I've recently been converting over to coding in Word. Assigning and using shortcut keys is more of a process in Word because alphanumeric keys are used for Word function shortcuts.
I should tell you that XyWrite is an older program used mostly by programming types now. XyWrite is DOS-based so I don't know if it will even run under Windows XP. It's an old friend for me but someone trying to learn it today probably wouldn't know what to do with the command line at the top of the screen (very useful if you know DOS commands) and would have to adjust to using function keys rather than the CTRL/ALT keys to execute commands.
There are folks out there who write scripts for converting Word coding to Ventura--Allan Shearer in Canada comes to mind--but your programs are so well executed and beautifully interfaced that it's worth paying for them even if the same functions are available free from other sources.
_________________________________________
RESOURCES
RMIT University has an excellent collection of links related to editing and publishing:
http://www.rmit.edu.au/links/publish.htm
