Anybody? Anyone at all?
Hard to know why - my guess is that it's something do with the font.
Does this happen with all fonts?
Are you fully patched on CS5.5.?
I'm not sure, but I just rekeyed your sample, used Fit Frame to Content, and then matched it with your column width to see if I could duplicate your bug in a fresh document. I sure can! But only if I'm using Times New Roman. No other font that I tested demonstrates this behavior. I didn't test with a very wide variety of fonts, but I did scroll through my list for a while trying to find another font that did this, but I did not. None of the other Microsoft Core fonts demonstrated this behavior, in particular, so I'm guessing it is a flaw specific to TNR Ital.
Ceencha, is your text frame top set to align to Capitals? Maybe there is a (very small!) difference in the caps sizes of TNR and TNI -- actual, or only in the font meta-information.
Maybe I can check that (barring mental shutdown due to continuous high temperatures over 'ere in Holland).
What are the version details from the used fonts?
See "Type"-Menu, "Find Font" => "More Details"
I cannot detect this problem with:
Times New Roman Italic
Times New Roman Regular
Version 5.07 over here, installed by default in Win7.
My Baseline Options were set to the default Ascent setting; when I changed 'em to Cap Height the last line was not overset by applying italics. In fact, for me only Fit Frame to Content + Baseline: Ascent + TNR + italics generates overset text.
Noooo, it is posible to make a text frame by hand that fits so perfectly as to generate overset text. I just wasn't trying hard enough, I guess.
And version 6.81 for Regular and Bold, version 6.80 for the italic varients here. Just a pointless "fact" thrown in.
HERE IS MY QUESTION:
Here is my answer.
It's because (1) the default top baseline align for a new text frame is Ascender, and (2) the value sTypoAscender in the TTF subtable OS/2 of a font is used to read this value out of the font.
topdist1 = app.selection.parentStory.lines.baseline - app.selection.geometricBounds; topdist2 = app.selection.parentStory.lines.baseline - app.selection.geometricBounds; alert ((topdist1 - topdist2)*2048/12);
-- select two textframes, one with regular text, and one with one or more characters in italics in the top line; then run this script. It shows the difference between the two in design units.
Additional proof? Try it yourself:
Times New Roman 1420
Times New Roman Italic 1422
Times New Roman Bold 1387
Times New Roman Bold Italic 1387
Arial, on the other hand, has an sTypoAscender of 1491 for all its styles. So does Georgia. So does Lucida Grande. So does Minion Pro. ... hold on ... Would TNR really be the only one?
.. A somewhat easier to understand version of the same script:
ascender = app.selection.parentStory.lines.baseline - app.selection.geometricBounds; alert (ascender*2048/12);
This immediately shows, for a selected text frame, the current ascender value that gets used.
Only valid for comparisons; the value shown is only valid for fonts with a design grid of 2048 em units -- you will get fractional values with, for example, a Type 1 font.
aargh. Had I not added the above clarification, then I could have silently edited the statement
which is 4096 units per em, for these fonts)
because it is 2048 units per em.