Who can give a scholarly definition of "type size"?

Uli's picture

A text typeset in 9 on 10 point using font A may look, as if it were identical with the same text typeset in 10 on 10 point using font B. This phenomenon is exemplified by me in this document:

http://www.sanskritweb.net/temporary/helve90.pdf

Who can give a scholarly definition of the notion of "type size" (or "size of type", "font size", "point size"), taking into considering this phenomenon as exemplified above.

dezcom's picture

If one were to take Bembo 8pt in InDesign or Quark and type a lowercase "g", type a return and then type the Acircumflex (or whatever diacritic glyph that is in the text of the book) and then adjust leading to just avoiding overlap, you could quickly make such a determination. I assume the rare Aringacute would be the worst offender (or anything in Vietnamese) but just base your decision on the language used in your book.

ChrisL

Uli's picture

Sorry, Mr. Lozos, I was speaking of "exactly".

William Berkson's picture

>no unnecesary space is wasted on the printed page by too generous leading?

>I was speaking of “exactly”.

"Too generous leading" is an aesthetic judgment, so there is no 'exact' you can specify objectively. As far as the minimum leading that will avoid vertical clashes, Chris's procedure will do that for you.

dezcom's picture

"Sorry, Mr. Lozos, I was speaking of “exactly”."

Uli, but it is exactly. You can type any value in the leading field down to 3 decimal places (one thousandth of a point) which is as exact as ever in the history of typesetting. You did not exactly define clipping or overlap in your statement but you can define that for yourself and use that value as the x factor. If clipping is zero then touching is your value. If you consider clipping as 1 thousandth of a point, then use that as the x value. That is much smaller than a brass or copper was in handset type.

ChrisL

Uli's picture

In photocomposition, the "minimum interline kp spacing" (k set directly below p) was 0.01 mm. So "minimum leading" would mean what was formerly achieved by "setting solid". Since a 3000-page book may contain innumerable clipping situations, an exact calculation of the minimum leading would be necessary.

dezcom's picture

In your example, the value of 0.01 mm is used as exact. In my example, 0.001 points are used as example of exact. Pick either one, the option is yours and not the least bit complex a calculation.

ChrisL

Uli's picture

Mr. Lozos:

In the meantime, I made calculations concerning Helvetica (instead of Bembo). Here, the exact minimum leading for any type size of Helvetica Roman is 15.6 % of the respective type size.

see http://www.sanskritweb.net/temporary/helve865.pdf

However, such calculations are not possible for typesetters who are not familiar with font editors so that the ordinary compositor in a printing plant will never be able to calculate the minimum leading required for solid setting of Helvetica, Bembo or any other PS, OTF or TTF font.

dezcom's picture

Uli,
I don't have your Bembo so I used another example. Here is a screenshot of Bulmer showing the precise value. It took me 30 seconds.

ChrisL

Uli's picture

Mr. Lozos:

If you used Adobe MT Bulmer OTF version, then e.g. the "§"-sign would be "deeper" then the "g", hence the value with "g" would not be exact. In the case of Bulmer, I calculate 8 point on 8.84 point, since the percentage would be 10.5 % for minimum leading.

dezcom's picture

As I said before, you can choose which ever glyphs to measure that suit your font, language, and book job. Your calculation of 8.84 sounds quite reasonable.

ChrisL

dberlow's picture

"...the ordinary compositor in a printing plant will never be able to calculate the minimum leading required for solid setting of Helvetica, Bembo or any other PS, OTF or TTF font."

All the data exists in the text of a document and the selected fonts in the formats you name, to do such a calculation, (i.e. all apps can know what glyphs are selected and all of the font formats carry glyph specific extent data). If no one has written a program to sort through the glyph repertoire of a text selection, flag the highest and lowest glyphs and determine the minimal/optimal leading for a given font, I'd be surprised, or maybe not...

The fact that we don't have such a thing built-in to apps, I suppose, means composers who care to avoid vertical crashing, do so interactively, as Dez so adroitly demonstrates. Knowing what the glyph repertoire is, checking that tallest glyph against a descender, and leading accordingly. Changing the glyph repertoire can change the answer. Changing the font can change the answer. Changing the size can change the answer. It's just like, changing the question, can change the answer.

Europeans have a similar process? Mentally filtering for A-rings, but otherwise leading to taste in the presence of another accented cap vs. the descender. It's a part of, typography. If a composer wanted only to pour text, and print quality typography, they'll need to either select from the 1,000's of fonts that behave 'normally' relative to their script/glyph use (which many 1000's of fonts do), write some software as described above, customize some fonts, or a combination of these things.

The fact that it is not a big problem with digital type, is also the reason the answer to the original question, is not simple.

Cheers!

Thomas Phinney's picture

Huh? No program or calculation is necessary. The piece of data needed is called the font bounding box (Font BBox) and is an intrinsic part of every TrueType or OpenType font. MS Office applications base their standard line spacing on the Font BBox (bbox plus 20%).

If you are using FontLab, go to File > Font Info > Metrics and Dimensions > Key Dimensions. At the bottom is the Font BBox info. Now, it's true that FontLab has to calculate this from the glyphs in the font (and it does so automatically), but once the font is made, nobody else does.

For Adobe's Bembo Std (licensed from Monotype), I find the BBox by poking it with a tool (could use FontLab, could use OS font APIs if the font were installed), and see that the regular face has a Y min of -233, and a Y max of 896, so the value Uli is looking for would be (233 + 896) or 1129. MS Word's default spacing would be (233+896)*1.2, or 1354.8.

Cheers,

T

Uli's picture

Thank you very much, Mr. Phinney.

At last, someone comes along and contributes some arithmetic calculations.

However, what was required for the lawbook mentioned above was the minimum leading for Adobe Bembo. The default spacing will not do here, because it is usually greater than the minimum leading (or minimum line-to-line distance). In case of Bembo, by using the bounding box data supplied by Mr. Phinney, the minimum leading calculation for 8 point Bembo is as follows:

(233+896) / 1000 * 8 = 9.032 point

This means, for minimum leading, you will have to typeset the text in Bembo 8 point on 9.03 point.

(MS Word does not permit of exactly 9.032 point leading or line-to-line space, for it rounds off to 0.05 point fractions).

The reason, why nobody in this thread could supply a scholarly definition of type size is quite simple: The notion of the type size does not exist any longer, as far as digital fonts are concerned. In the "good old days", i.e. in the foundry type era, the size of type was measured from the hightest to lowest characters, as shown in this old American printing handbook:

http://www.sanskritweb.net/temporary/sizeoftype.gif

And the scholarly definition of type size usually met with in books at that time was (in my wording) as follows:

Type size is the vertical dimension from the top of the highest ascender (in case of Latin types) to the bottom of the lowest descender, measured in typographical points (e.g. using the American point = 1/72 American inch).

This definition for foundry type could be directly transferred to the modern notion of the vertical dimension of the glyph bounding box, but there are three major drawbacks:

- Firstly, the vertical dimension of the bounding box is expressed in relative units, whereas the type size of a foundry type letter was expressed in absolute points.

- Secondly, no user of a word processing program (as opposed to the user of a font editor such as Fontlab etc.) sees this relative numerical unit value of the vertical dimension of the bounding box in his application program (MS Word, Adobe InDesign etc.).

- Thirdly, leading in the sense of foundry type does not exist any longer. Remember: Leading in the foundry type era was the space between two lines, whereas the usual word processor programs measure the "line size", see here for example:

http://www.sanskritweb.net/temporary/linesize.gif

So, you cannot enter the "type size", you can only enter the "line size", which is defined as the "line-to-line distance", measured in points. If the old notion of "type size" still existed, then you would be able to enter the "ascender-to-descender distance", i.e. the absolute vertical dimension of the glyph bounding box in points (not in units), but this is not possible (as least not in the word programs known to me).

One of the absurd consequences of all this is the fact that two congruent headlines may have different "type sizes", as shown in the beginning of the thread in this file:

http://www.sanskritweb.net/temporary/helve90.pdf (page 10)

In view of this Helvetica sample shown on page 10, Mr. Berlow said:

"I would say, both samples are typeset in the same point size".

But this is not correct, because for the first typeset word "Helvetica", the "point size" entered in MS Word was 90, and for the second typeset word "Helvetica", the "point size" entered in MS Word was 100.

In my opinion, the point size should refer to the vertical dimension of the letters, not of the line, i.e. when you enter e.g. the number "36" for Times as shown here:

http://www.sanskritweb.net/temporary/linesize.gif

this should denote that you enter the vertical size in points from the highest to the lowest characters of the font (as specified by relative units through the bounding box).

William Berkson's picture

>in the foundry type era, the size of type was measured from the hightest to lowest characters

Uli, your source is not correct. The type size in foundry type is normally the same as the 'body size', the vertical height of the piece of metal. This includes not only the face, but also the 'shoulder' or 'beard', which is the part of the metal between the face and the edge of the metal block. And for mechanical reasons there was almost always some shoulder.

And the face could be smaller or larger on the body. Also sometimes type was also cast on a larger body, so you'd have "12 on 13" or something like that.

So even in metal things were more complicated.

>In my opinion, the point size should refer to the vertical dimension of the letters, not of the line

As the above indicates, this was not ever true, even for metal type.

Uli's picture

Mr. Berkson:

> Also sometimes type was also cast on a larger body, so you’d have “12 on 13” or something like that.

This is correct. Technically, for hot-metal text typeset in 12 point on 13 point, you could either set the text in 12 point and insert a 1-line brass reglet for leading. Or you could cast letters containing the 1-point leading as part of the lead-metal body. But this does not change my definition. In both cases, you have 12 point text, irrespective of whether the leading is brass reglet or part of the cast lead-metal letter.

Correction: "The word "brass" is not correct. For leading, a special alloy was used, harder than foundry type.

William Berkson's picture

Uli, maybe I wasn't clear.

Because of the existence of the shoulder (which is lower than the face), the body size of metal type is almost always larger than the distance on the face from the top of the highest to the bottom of the lowest character. And how big the shoulders are varied from font to font. Hence even in metal there is not a unique relationship between what is now called the 'bounding box' and the body or type size.

Hence your definition of 'type size' is not correct for metal.

dezcom's picture

"The reason, why nobody in this thread could supply a scholarly definition of type size is quite simple: The notion of the type size does not exist any longer, as far as digital fonts are concerned."

This is what we all have been trying to tell you, Uli. The value in the measurement and how it was done in the metal type era has gone the way of the steam locomotive. A fireman on a steam-powered train years ago could have told you how many shovels full of coal it would take to travel from point A to point B and he would be able to see if enough remained in the coal car for the journey. Today, they would use diesel fuel instead of coal but they would have no need of knowing about calculating coal consumption or translating the rate of coal consumption and translating it to diesel fuel consumption. Today, we use the tools of today for both train travel and copyfitting of type. We can copyfit much quicker and more accurately today than ever before. Yes, this digital way makes obsolete the methods we had become accustomed to but the end result is that we come to a more accurate answer and more speedilly than before. That seems like a fair trade off.

ChrisL

Thomas Phinney's picture

Although I mostly agree with Chris L, I'd add that there is no techical reason an application could not allow you to set type in terms of the Font BBox size.

Actually, Word and its friends do, essentially. The complication is that their base spacing is 120% or 6/5 of the "set solid" BBox value. But you can set spacing in Word as 5/6 of that (0.833333) and set the type solid on the Font BBox. You'll be doing it without ever knowing what the spacing is in points or any other absolute measurement, but it will work.

That being said, the problem with this is that heaven help you if you revise the font in a way that, say, adds a glyph that has the effect of enlarging the BBox. Also, sometimes you simply might not want certain glyphs to affect the overall line spacing. Just because there are some big ornaments in the font doesn't mean you want the spacing of text to loosen, IMO.

Cheers,

T

John Hudson's picture

Actually, Word and its friends do, essentially. The complication is that their base spacing is 120% or 6/5 of the “set solid” BBox value.

As far as I know, in most situations Word and most other Windows apps use the OS/2 WinAscent and WinDescent values to determine default linespacing, and those values may or may not actually correspond exactly to the font BBox. They certainly shouldn't be smaller than the BBbox, but in quite a lot of fonts they are padded to provide extra linespacing. There are a few reasons why the OS/2 Win metrics values might exceed the BBox, of which the best would be forward-thinking on the part of the font developer who knows that a future version of the font is likely to include added support for Vietnamese or some other taller glyphs, and in order to be able to both maintain linespacing compatibility and avoid clipping of the new glyphs a canny developer might set the OS/2 metrics larger than the current BBox in anticipation. There have been a couple of times when I really wish I'd done that!

Note also that in Word 2007 the default linespacing in non 2003 compatibility mode is 1.15 spacing.

Uli's picture

Mr. Berkson:

Because of the existence of the shoulder (which is lower than the face), the body size of metal type is almost always larger than the distance on the face from the top of the highest to the bottom of the lowest character.

Here you are right too. Later in photocomposition, the "minimum leading" could be zero (although, e.g. Berthold used a default "minimum interline spacing" of at least 0.01 mm), but in hot-metal composition, the "minimum leading" was more than that, due to technical restrictions mentioned by you.

Uli's picture

Mr. Phinney:

... that their base spacing is 120% or 6/5 of the “set solid” BBox value.

This technical information given by you was very useful.

I at once made a test and I confirm your information that e.g. MS Word 10 (run on Windows XP) adds exactly 20%. My test is shown here:

http://www.sanskritweb.net/temporary/default.pdf

See also the "psychiatric note" at the end of the file.

dberlow's picture

"Huh? No program or calculation is necessary" and more Thomas, "Now, it’s true that FontLab has to calculate this from the glyphs in the font (and it does so automatically), but once the font is made, nobody else does."

Oh? When the 'font' contains all of the glyphs for all of the languages, i.e. it is sized to the em and populated with glyphs at the foundry for general use, and not by 'a user's' glyph requirements, and the requirement for a particular 'text' or 'document', perhaps from use of only english or just numbers, doesn't use everything in the font, then the font's bounding box is not the bounding box the user needs to know, if they need to know...you know?

The calculation of the bounding box required by the particular repertoire for a particular text, does not exist. The bounding box is 'foundry font' specific, not 'use of font' specific, understandably, but incompletely in my opinion.

Uli: "In my opinion, the point size should refer to the vertical dimension of the letters, not of the line"
Then take your opinion, and make a whole library of fonts that work that way. I'll be waiting with a team of shrinks, or maybe not.

Cheers!

Thomas Phinney's picture

I agree with both David Berlow's and John Hudson's comments above. And I don't know how I forgot that Windows is using usWinAscent and usWinDescent. These are commonly and by default the same as the font BBox values, but not *necessarily* so.

Regards,

T

Syndicate content Syndicate content