Typophile

Three typographic style questions

splinter

1. If body text contains small caps, what would happen if in equations/formula there were capital letters as well, would you use small caps for them?

2. Superiors/subscript, how are they to be best set? I know some fonts have them built in, but are there any guidelines for how the can be best set? One guideline could be, for superiors, align them with the top of the body text ascender, then align the bottom of the superior with top of the x-height. For subscript, align the top of the superior with say half the height of the x-height, then align the bottom of the subscript with the descender?

3. What is the best way to set numbers in tables? Should they always be set right aligned and the numbers should not be old style, so they align up, and does this really help readers?

1. I think the equation is clearer when you use regular caps.
2. Use a font that looks like the one you want to give superiors/subscript which has them build in and use it as a guideline. Best is to simply go for a font that has it already built in.
Use tabular lining figures, if your font doesn't have that, make sure they're all the same width (including spacing+kerning) It doesn't really help readers, but it's more comfortable to read, i guess.

1. Good question. I don't see a problem to use small caps if they result clearly identified as caps in the formula. But most fonts have small caps with the same height of lowercases. This produces rather small characters, probably so much small to replace a uppercase in a formula. In other hand, there are many new fonts with bigger small caps and this seems to be the best choice. Of course, you must do tests to evaluate it better.

2. Traditional superscript setting is size reduced to 58% of normal one and position with +33% of baseline shift. Nowadays, many designers consider this somewhat small and you can find larger superiors in recent fonts (Guardian, Meta, Vesper). Additional information here.

3. Numbers in last column at right must be aligned right. To other columns, this will depend on your data. If you are handling many columns with numbers, overall alignment at right seems better. With decimals, the decimal dot alignment is preferable. When mixing text and numbers, I prefer to use left or justified alignment.

Tabular numbers makes sense if exact vertical alignment means something to your table. For example: accounting data, where reader would compare numbers between different lines, is a typical scenario for tabular numbers. But for tables with few numbers, menus, timelines or TOCs (for example), tabular figures are not necessary and may be even distracting.

Part of your question is, who are you designing for? If you're entering book shows, and your audience is other designers, use small caps everywhere -- Well, maybe not to begin a sentence. But I've seen the word "TiVo" with small caps used for the "T" and "V". Just because it is hard to read doesn't mean it isn't really cool.

If, on the other hand, the text is suppose to be read by people in a particular field, like mathematicians, take a look and see what they do. (Hint: I've never seen small caps substituted for full caps in an equation).

The same would apply for old style versus lining figures in a table. A series of dates and dollar amounts, for example, reads quite well when set in os figs, particularly in a book dealing with the 19th or earlier centuries. Did you think they didn't set tables before Victorian times? Once again, what would the audience be comfortable with, on the assumption that audience isn't graphic designers.

Go to the library. Take a look at the first-line journals in the field. When you feel you want to challenge their ways of presenting information, write your own book. Keeps everybody honest.

.

"Numbers in last column at right must be aligned right."

Why must they always be aligned right, out of curiosity? I can understand from an aesthetic point of view, but I would think that the readability of the column is better when the figures are left-aligned, no?

Just one more instance of "If it's Tuesday, it must be Belgium" kind of thinking. Typically, the widest element in the last column is "aligned right" i.e., goes to the right edge of the table, but even that is full of assumptions. The data may well be decimal aligned, and one element may have more numbers to the right of the decimal. The column head too is a factor -- sometimes the shortest element in the column head is longer than any entry in the column. If the general style of a table is for the data to center under the column heads, a long word in the column head may set the right margin. Even more so when the style is for the data to be left on the column head.

Then, not all tables are full measure, nor is all placement of tables less than full measure "right" or "left" on the text page.

Finally, there are the rules -- top, middle, bottom -- that can be used to give the table a desired width. Often they are just the width of the elements in the table, but they can be extended. Just the ticked when you're setting a table on a 26-pica page, but the data, with reasonable gutters, only reaches 24 picas. You can ether add space to the gutters, or extend the rules to reach 26 picas. If you extend the rules, in effect you have a dummy column on both the far left and right of the table. Alternatively, you can set the table short, but as it approaches the full measure of the text, that usually looks odd.

The most common approach with the "almost" table above is to just add space to the gutters. For those of you who actually read tables, you know that too much gutter space can make it hard to follow the alignment of the data in a row. Using a dummy left & right column can be a good solution.

Designing good tables can be as involved as designing a text interior.

When dealing with mathematics, I'd be rather reluctant to substitute anything for anything without consulting someone working in the relevant field. Caps and small caps may very well have different semantics in the subfield in question.

André

Just one more instance of "If it's Tuesday, it must be Belgium" kind of thinking.

Just one more instance of misuse of other's words. It's completely incorrect to compare my answer, valid for general and most common situations, and a nonsense statement as "If it's Tuesday, it must be Belgium". You don't need to distort my advice to add your own, especially when you are handling exceptions to general rules considering other graphic elements and particular situations.

.
Why must they always be aligned right, out of curiosity? I can understand from an aesthetic point of view, but I would think that the readability of the column is better when the figures are left-aligned, no?

The aesthetic question is relevant. But there is also the readability of numbers. If you have just numeric data, right aligment is more adequate because our number system is based on RTL position. So, to quickly identify and compare different quantities, a right aligment is better because it preserves the position of units, tens of units, hundreds etc. The same justifies use of decimal aligment when there are numbers with decimals.

"It's completely incorrect"

If anything is «completely incorrect» in this discussion it's general statements. (Ah, the irony.) «Numbers in last column at right must be aligned right.» Must! Across all tables in the world, ever, no matter what they may contain, what the layout looks like, how wide the table is (and the column), and what the number is…

What Charles said (who by the way is being entirely fair in this discussion I think). Typography is a jungle, a muddy continuum of interlocuting variables, not the open country of hard-and-fast rules and laws – no matter if somebody specifically asks for the latter. Yes we can have signposts and maps, but they're never absolute.

Mr. Freiberger:

I think the term you want is simply "decimal aligned." This applies whether there is an actual decimal or not. It says simply that within the column, 1s, 10s, 100s, etc, all share a common vertical position.

It says nothing about where things are located within the column. That's where the miscommunication arises. For example, numbers can first be decimal aligned, then centered, flush right, or left.

What does bother me is

especially when you are handling exceptions to general rules considering other graphic elements and particular situations.

Ah, but who's rules? Readers? Editors? Typographers and graphic designers who've done little of either? Or typographers and graphic designers who who work a lot with both?

Nina, you're mixing matters, using a technical opinion about design (general statements are incorrect) to justify as fair a behavior I did repute incorrect (to compare a rule valid for general situations to an illogical affirmation).

I can see my "must" was a bad choice and I apologize for giving the impression it was an absolute rule which does not admits exception. But I keep my opinion about the comparison to be objectively incorrect – and thus, unfair.

Sorry if "unfair." How about this? You're wrong.

As a general practice, rule or not: with the exception of the stub, the most common arrangement of numerical data in a column is decimal aligned, and centered under the column head. The far right column should be no exception. In the cases where the column head is shorter than the data, the data will perforce be flush right. In my experience, IN GENERAL, column heads are wider than the data in their column.

EDIT:

And as long as we're going to fight, using small caps in equations goes against all established conventions. You might as well say that sentences can begin with small caps, except for c, o, u, v, w, x, and z. Get that one by an editor.

In passing, variables expressed with letters in math are usually set italic. The number of fonts with italic small caps is growing, but far from universal.

In short, your advice sounds uncritical to me; a knee-jerk reaction -- so we're back to the old cartoon of Tuesday and Belgium.

You will have to fight alone as I think it's a waste of time to keep this going.

Word

Captured from web.archive.org on 28 Nov 2010. view this capture