Re: FONT STANDARDS
No one seems to be biting today, or perhaps only off-list. Courier makes me cringe due to it's ugliness.
Courier *is* ugly, and not all that readable. I much prefer Andale Mono for my own onscreen use (console windows, terminal emulators, default mono font in the web browser). But no publisher is going to pay the royalties to use it.
Anway, "ugly" is a secondary consideration. Communicating clearly is primary. With that in mind...
My doucments are usually:
tahoma for commands and strings (all code), unless is a publisher protocol to use something like times or arial, which it is for certain publishers I've worked with.
I just looked at samples for those fonts (well, Times New Roman, since I don't have any postscript fonts on my machine) and for Courier New.
Something in me rebels at using a variable-space font for command-line or code samples. But I have to admit that Tahoma is rather more readable than Courier. The big advantage is that it's very clear which is lower-case-l and which is numeral-1. I don't quite like the way Tahoma does a capital-O (so as to distinquish it from Zero-0) but it's acceptable.
Arial seems to be close enough to Tahoma not to matter. I seem to recall that Arial is a Microsoft clone of Helvetica, which is worth knowing if you're using Postscript fonts.
tahoma for file names, but rarely do I ever use file names in doco
I reluctantly agree. But you're doing work very different from mine if you never use file names!
tahoma bold for menu selections separated by | as in File|Open> tahoma for dialog buttons or screen buttons but tahoma bold for dialog
tahoma bold for keyboard, and menu
> or screen name
There really needs to be some careful thinking done here, and no just in the font. I wish writers and editors would invent concise ways of conveying this stuff. I hate reading "Choose X in the Y menu, then choose Z". It's hard to follow.
FONT STANDARDS: From: Anna Langley
Search our Technical Writing Archives & Magazine