What are some good fonts to use for a highly technical document? Is there any specific type that should be used/avoided?
-
1Perhaps you could add a little detail on what you mean by 'highly technical document'? Does it contain very complex tables with small text, equations, complex labelled diagrams, charts, program code?– e100Commented Jan 5, 2011 at 17:56
-
4Comic Sans MS should be avoided at all costs, in anything you do.– Mateen UlhaqCommented Jan 7, 2011 at 4:15
-
Technical documents? Like readable technical text or just technical annotations?– Robert KoritnikCommented Jan 19, 2011 at 8:19
-
1CERN (the temple of physicists) decides to switch to Comic Sans :)). home.web.cern.ch/about/updates/2014/04/cern-switch-comic-sans– OokerCommented Jul 7, 2014 at 15:06
6 Answers
Technical documents will have a deeply nested, hierarchical structure, and also make use of footnotes, different types of emphasis, cross-referencing, pull outs and side bars of one sort of another and captions. The main distinguishing feature of technical documents tends to be complex structure.
For headings, you can use any reasonably legible font; this could be serif or sans-serif. It should have a complementary style to your body text, but the headings should provide an obvious visual structure to the document.
A decent serif or sans-serif typeface is fine for the body text if you have a lot of prose. If you have a lot of illustrations with labels or captions, pull-outs or tables you might want to use a sans-serif font for the body text and a serif font for headings. Footnotes will be smaller than the body text, so don't use a font for the body that is too small.
For emphasis, the italic or oblique version of the font should have a noticeably different texture to the body text.
For tables, captions and pull outs you should use a sans-serif font in most cases. If you use a serif font for the body text make sure the texture of the sans-serif font complements but does contrast significantly from the text type.
If you intend to have code listings or other monospaced items in the document then you will have a third typeface for the monospaced text. This should visually complement any sans-serif typefaces. Don't use Courier for this as it is relatively wide; other monospace fonts such as Lucida Console will give you more monospaced characters in the same width for the same point size or general legibility. Also, Courier doesn't really go with anything and the version that ships with most O/S platforms is very light and not terribly legible for reading large code listings.
If you have the option of buying in the fonts then you can pick any combination that looks appropriate; many resources on the web have helpful suggestions for this.
If you are stuck with fonts supplied by your operating system vendor then the story is slightly different. Although I briefly worked as a typesetter about 20 years ago most of the technical documentation work I do these days is functional specifications and I am typically constrained by the software available in the client's standard desktop build.
Some options are:
Palatino is quite a pleasant typeface for text if you are writing large bodies of prose. It got done to death in the DTP era as it came bundled with most Postscript printers, but that is a bit of a dying memory so it can stand on its own merits. It will go with any of the Sans-serif fonts (Arial, Tahoma, Trebuchet, Calibri etc) that ship with Windows. MacOS and most Linux distros also come with a decent rendition of Palatino from Adobe or URW.
The Lucida family is designed for this type of work, and has serif, sans-serif and monospace fonts. It has a pleasant, contemporary look and works well. Another big plus is that most O/S platforms come with Lucida fonts. The Lucida family was also designed to render well on low-res output devices such as screens or early laser printers, so it is a good choice in a font intended for PDF output.
Stand-bys Times and Arial (or Helvetica) work OK, although I find that Times italic tends not to stand out very well on laser printed documents. The document will look like something done with MS Word, but the typefaces are serviceable. The main reason to avoid these fonts is personal taste or a desire to avoid looking like amateur word processing (which may be more important than you think if you need the document to be taken seriously.)
Traditional old-style or transitional types (e.g. Garamonds, Bembo, Baskerville) look quite nice and are legible in text, but have a low x-height so they need to be set in larger sizes. Mixing these inline with a sans-serif typeface with a bigger x-height can look strange. ITC Garamond (Used extensively by Apple in the 1980s and 1990s) is a re-imagining of Garamond with a larger x-height, so doesn't suffer from this problem.
Moderns such as CM or Century Schoolbook got done to death in the 19th and first half of the 20th centuries, so they tend to come with a lot of cultural baggage. I find moderns make a document look like something from the Victorian era or the 1920s or 30s. While they are quite practical and legible, I must beg to differ with DEK about their appropriateness for technical documents.
Take the usual hints about care when mixing humanist and geometric typefaces. Note that highly geometric sans-serifs like Avant-Garde Gothic or Futura aren't really suitable for text type for a technical document. Although they may be OK for headings, if you have a lot of captions, labels or otner sans-serif artifacts in the document they will clash with AGG or Futura if not set in the same typeface. This is a strike against using these fonts for anything but major headings such as chapter titles. Similar issues apply when using any sans-serif font with a highly distinctive look.
From memory, I have had good results with text type set in Times, Helvetica, Charter, Palatino, Frutiger, ITC Berkeley Old Style, Calibri, Tahoma and one or two others in various technical documents I have been involved in writing.
Some combinations I have used are:
Times text and Arial headings, captions and labels with Lucida Typewriter listings (dictated by corporate standards)
Palatino text and Helvetica headings, captions and labels (Adobe fonts, designed to be rendered to PDF without having to embed fonts so I stuck with the 35 standard PostScript fonts). The document was produced with Framemaker.
Palatino text and Tahoma headings with Lucida Console listings. In hindsight, the bold on Tahoma that comes with Windows is too heavy.
Cambria headings and Calibri text - defaults with Word 2010, and look OK together. Shrink down the heading styles from the default sizes - the bold is quite heavy and it looks too strong against the body text. Also, the default style inserts quite a bit of leading in the text styles.
Charter, CMSans, - document produced with LaTeX. This used the basic 'Charter' style that comes with LaTeX, modified a bit by hacking about the includes.
ITC Berkeley Old Style/Helvetica. Headings and text done with BOS and captions and some other bits done with Helvetica. I like Berkeley Oldstyle as a font (try setting the word 'Quidditch' in it) and it works for both display and text type. The ITC version (predictably enough, I suppose) has a fairly large x-height, so it works with sans-serif fonts.
Lucida - comes with pretty much every major OS platform, is highly legible, and is designed to render well on low-res output devices such as laser printers. There is a whole family of serif, sans-serif and monospaced fonts available. They render well on screen, look nice in print and have good ergonomics for technical documents.
EDIT: Actually, this reminds me of a story. At the university where I did my bachelor's degree they had a course that (amongst other things) teaches LaTeX and the joys of structured documents. My friend was a tutor for that paper at one point. One of the students complained about LaTeX thus:
But if I use LaTeX all my documents look like they were done in TeX
To which my friend replied:
Could be worse. Could look like they were done in Word.
The student saw the point.
A corollary to that is that one of the lecturers actually did some stats on this at one point and found a correlation between grades for assignments and using LaTeX. He swears that using LaTeX for an assignment is worth about half a grade on average. Whether this was due to the structured documentation effect and auto look-and-feel features of TeX or just because the smarter students tended to used it wasn't made clear, although I think he may have attempted to correct for the average grades of the student.
-
2Lucida Console not the best font for code samples: '0' and 'O' aren't easily distinguished. Inconsolata and Consolas both have slashed 0, but may be worse in other aspects.– citrinCommented Oct 7, 2016 at 14:48
Technical documents are often set in sans-serif. There are a couple of reasons why this is preferred over its serif counterpart:
Serif typefaces are usually designed to be as transparent to the reader as possible. In a novel, reading should be a fluid activity, and the typeface must not call attention to itself. Technical documents are often filled with important notices where the reader is supposed to make stops, and be the structure must easily "scannable" with your eyesight.
Sans-serif allows for a greater range of weights, from thin to black. Technical documents often have deep, nested hierarchy, and having many weights at your disposal allows you to transmit this hierarchy.
A pair of good choices for technical documents are:
Whitney is a very complete typeface with a very wide range of weights. It also provides "lining figures" which are great for tables and such. It also has built in numbers and letters encased in circles and squares, which are very handy when making annotations.
Thesis is a serial typeface (it has serif, semi-serif, mono, semi-sans, and sans-serif choices), also in a very wide range of weights. It's monospaced font allows you to write code in the same great looking typeface.
For technical documents (or any other type) I have found the 'So You Need A Typeface' document to be very useful. It started out as a little bit of a joke around here, but it's actually incredibly useful. I've got a blown-up copy of it hanging on my wall.
-
1Are you alone? [Yes] Ok, then come with me. - - - - - - (long walk) - - - - - - - - > [Comic Sans] :-D Anyway, the second link is broken, I've uploaded it to imgur to save it for future lurkers, all credit to Julian Hansen who's website seems to be down.– vgruCommented Feb 18, 2016 at 9:34
For any technical document the goals are to maximize readability, while reducing potential ambiguity.
For me this means my first rule is:
- Numerals or figures should be distinct from letters, as with the modification to Brioni to clarify the digit one. I really like to see a distinction between the capital letter O, and digit zero 0, whether through a slash, through narrowness of the zero, or another indicator. In technical writing a label of combined letters and digits may be used, particularly in randomization of samples during experimentation, and in source code for programming. So ISO451 should be clearly distinct from IS045I.
After that, my suggestions would be:
Text or non-lining figures in prose in often fine as long as it is not distracting, and lining figures for most other uses, using tabular and proportional as appropriate.
In technical documents the jargon or technical words used may not have the normal amount of redundancy of information (entropy) we are use to in natural text, so ambiguous characters may be intractable in complex cases such as name of a novel pharmaceutical compound. In principle, if a typeface would obviously be a poor choice for OCR, I would avoid it. Not that I would be slavish to actual performance of the typeface and any given OCR software's performance.
Typefaces should be non-tiring to read if they are used as body text. Times New Roman, and New Century Schoolbook are boring, but easy and non-tiring to read a large amount of prose in. A modest to lightly serif is my personal preference, but a sans-serif suitable for body text for prose published in a book form (say university level textbooks), then it may be suitable.
Depending on the document's media, e.g. a blueprint or CAD drawing, if it is space constrained consider using a semi- to condensed sans-serif typeface in captions, labels, etc. to maximize the information density.
Follow any existing conventions of the genre. For legal technical documents, Typography for lawyers , is a good place to find conventions. For more academic areas, research journals publish a style guide or handbooks for paper submission with the publisher's "house" style and genre's conventions. Book publishers have similar guides for their various technical and reference imprints. Even standards (e.g. ISO, IEC, IEEE, etc.).
Respect the target media (screen, laser printer, tablet) and how it will be used (e.g. in dirty work environment with messy machinery, sections photocopied as check lists, etc.) for selection of typeface size. Footnotes might look better on a 30 inch screen in 8 point font while you set the document, but at 3am in the morning, – regardless whether it is reviewing case law, or doing emergency plumbing – at such times, clarity is the only style I care about.
Highly technical documents (I'm assuming scientific) should use STIX, without a doubt.
STIX is a free open source opentype font with a library of technical symbols that is unrivaled.
Generally speaking, serif fonts like Times are Palatino are considered good for printed media and sans-serif fonts like Helvetica for use on computer screens. Anything in code, however (HTML, C++, what have you) should be rendered in a fixed-width font such as Courrier New.
-
Actually, I've seen code pleasingly rendered in variable-width fonts. This doesn't cause any problems as long as the use of whitespace for alignment is limited to indentation levels (e.g. no internal alignment of multi-line comments or text strings). It also has the benefit of allowing longer unbroken lines (pretty much every fixed-width font has a painfully low number of characters per line for typical text block widths). I'm not ready to use variable-width fonts in my editor (yet), but for printed material I think they're great.– Steve SCommented Jan 12, 2011 at 17:41
-
2Generally I recommend against using Courier for code listings for a couple of reasons. The first is that it is quite wide; you will get more columns in the same width from others such as Lucida Typewriter at a useable point size. The second is that it's quite ugly and doesn't really go with anything else, but that's a matter of personal taste. Commented Aug 25, 2011 at 13:22
-
I think serifs are now considered okay on very high res screens (higher than HD, 1920 x 1080). Definitely okay for headline text at HD. Commented May 6, 2016 at 17:35