Solved: How many points is 12-point text?

[WorkerBee]

OK, I thought I knew something, but it looks like I don't.

I THOUGHT that 12 point typefaces were 12 points (12/72" or 1/6") tall so that two twelve-point lines of text would be 24points tall, six lines should be 72 points (1") tall. This would lead me to think that on an 11" tall page with 1" top and bottom margins, we could fit 54 lines of text (6 lines x 9 inches).

But nearly all the typefaces I try are somewhat bigger than that, even the mundane Courier New and Times New Roman. Only a couple of odd typefaces (Hartin2 and UpperWestSide) give me the proper count.

Is this sloppy typeface design, or inappropriate expectations on my part? I'm not surprised when a typeface like "52 spheroids" or "Bark! Bark" is not up to specs, but why isn't "Courier" 12 points tall?

I'm madder'n hell, and I DEMAND an explanation!

-Curt

[EdgeMMG]

Don't forget about leading, or the amount of space between lines, measured baseline to baseline. (bottom of say, the letter e, to the bottom of the letter e on the line above it) To prevent overprinting, this is usually at least 2 points larger than the point size.

One line of 12 point type could equal one pica (12 points, 1/6 of an inch) in height. Two lines of 12 point type would end up being roughly 26 points. (12 for the line, +14 measured baseline to baseline, ie. 12 for the second line, 2 extra points of leading to prevent ascender/descender overprinting)

[MOS MASTER]

Hi Curt, :D

Never have done so much testing on this kind of things.

Could you provide us with a testdocument so I can try to reproduce your problem. (and look for an explanation)

Could you also discribe your testing method?

By the way can you tell me the value of measure units on Tools/General? (Mine is Centimeter..think yours will be points)

Enjoy! :whistle:

[WorkerBee]

Hi, thanks for the helps...

First, I figured out a thing or two.

Unless the paragraph description is set to 'Exactly 12 points,' the line spacing will be somewhat more than 12 points. Once it's set to EXACTLY, the vertical spacing is correct, the leading built in to the 12 point line size.

What's driving me crazier is that I cannot seem to get a reliable value for the vertical position relative to page.

The interesting phenomenon I've encountered is when I create a very long paragraph with a line spacing of EXACTLY 12 points, and populate it with a lot of text that's 12 point text. If I move the curser from bottom of paragraph to top, running the little VBA code (below) on each line and subtracting one value from the next (which should give me the reported distance from one line to the next), I get different values ranging from 11.85 points to 12.7 for different lines.

I was expecting that each line would be reported to be the same distance apart.

From page to page in a longer document, where there are various numbers of paragraphs of different styles, some with different 'before' spacing, I get a different value for the largest-permissible vertical position on the page, which makes it difficult to automate some page-breaking routines I'm trying to implement.

Is it possible that the "Selection.Information(wdVerticalPositionRelativeToPage)" is not functioning correctly? It causes some very unpredictable results.
Here's the code I've been using for testing. (It's embedded in the attached document, too).

Sub Test()
Dim VertPos As Variant, Response As Boolean
VertPos = Selection.Information(wdVerticalPositionRelativeToPage)
Response = MsgBox("The vertical position reads: " & VertPos & " points." & Chr(13) & "In inches that might be: " & VertPos / 72, vbOKOnly, "Help!")
End Sub


I've attached a .dot file which has the code above and a bunch of paragraphs, if you want to try it out yourself.

-Curt

[MOS MASTER]

Hi, :D

I Dunno :dunno if "Selection.Information(wdVerticalPositionRelativeToPage)" is not functioning correct!

But I can understand it would look like that because it depends on so many factor's to give the correct count every time you're at the last line.

In your example it's working correct. So one must assume that somewhere in al those different styles you forgot one little detail of a particular style that's causing the different outcome of information property.

I will try some things and I'll come back to yah. :whistle:

[WorkerBee]

I've found that the values returned with the selection.information(wdverticalpositionrelativetopage) vary with the current zoom setting. This makes no sense to me.

I've also had it change values when I typed a new character into the paragraph, but I haven't been able to repeat that little trick.

Unfortunately, this function does not really return an accurate value. If it did, that value would not change with the zoom setting.

-Curt

[EricFletcher]

EdgeMMG is on the right track: the spacing between lines (correctly called leading) is a different measurement than the font size. Two different 12pt fonts will have different dimensions: the "x" height, ascenders (like "b" or "l"), descenders ("g" or "y"), and accents ("?" or "?") all vary depending on the font design. Compare Arial versus Garamond to see some fairly obvious differences.

The leading is assumed in Word, whereas many typesetting programs specify it explicitly. For example, "Garamond 12/13" would mean Garamond 12pt with 13 pt between lines. In Word, if you specify "exactly" 13 pt, the display will not show all of a subscript or superscript, and a word set in 18pt size will appear with the tops chopped off; if you specify "At least" 13 pt, the line with the 18pt word will be spaced enough to display all of the 18pts, and any sub- or superscripts will display fully.

If you want facing pages to have exactly the same number of lines, or want all pages to fully fill the vertical margin area, you should use the Exact specification within the Format Paragraph dialogs -- but keep in mind that you'll need to specify that any subheads (plus any other elements) have exact multiples of the chosen body leading. For example, 54 lines of 10pt type on 12 pt leading will fill a page that has a vertical text area of 648 pts (9") but if you have a subheading, be sure that the total of the space before, space after, and its own line spacing is a multiple of the 12pt body leading, or it will throw off the vertical position of subsequent lines on the page.

I suspect that the reason your code reports differences may be due to where the cursor is deemed to be on a given line relative to the character at the start of the selection. I wouldn't rely on it for an accurate indicator of the line's position -- although you could test that by using a page with the paragraphs all made up of the same character I suppose.

[WorkerBee]

Well, I've spent too many hours trying to make sense of this. I've tried all manner of theories such as Eric provides, but cannot find any consistancy in the reporting of vertical position.

The fact that this value changes with the Zoom setting, leads me to conclude that the value returned is inter-related with the position of text on the screen display, and not strictly the actual position of text relative to the top of the piece of paper it's to be printed on. It is therefore a value that's too dynamic to be useful for my particular application.

[geekgirlau]

Have you also tested this with


Selection.Information(wdVerticalPositionRelativeToTextBoundary)