Isn’t it because of the ascenders positioning within the typeface_?

It seems that different applications on different platforms use different ones of these, and do vertical alignment differently. The Typowiki on vertical metrics, written by John Hudson, has quite a bit about it.

That’s mainly about cross-platform compatibility.
In it, he says, “...different methods are used [by different applications] to calculate the distance from the top of the text frame to the first baseline,” but doesn’t go into it any further.

I was wondering which font metric governs the text-frame-to-baseline measurement in various programs, such as Quark in my example.

I try to keep the final Font BBox measurement (top right y-axis value) consistent within font families, that seems to work, but I wondered if there was more to it than that.

“What is it that causes the positioning of fonts relative to the top of a text box?”
We’ve been asked several times to “fix” this and we’ve made the top of the em square and top of the H the same.
The response has been positive.

Cheers!

Thanks David!

How do you adjust the em square?

“How do you adjust the em square?
I’m not sure what adjustment you want to make;
There is resolution of em, like 1000 or 2048, er something else.
There is the position of the baseline within the em.
There is the font’s relationship to the vertical boundaries...

Cheers!

What Read Roberts found on the Mac was that some applications calculate the distance from the top of the text box to the baseline of the first line of text as hhea Ascender, and some calculate it as hhea Ascender + Linegap. On Windows, OS/2 WinAscent is almost always used to calculate this distance. So the only way to ensure consistency everywhere is to match the hhea Ascender value to the OS/2 WinAscent value, while setting the hhea Linegap value to zero, *presuming”

I’m not sure what a WPF app will do to calculate the distance if fsSelection bit 7 has been set to instruct the app to use the OS/2 Typo values to calculate linespacing: it may use TypoAscender, or it may use TypoAscender + TypoLineGap, or it may use WinAscent. Of course, if you have made the decision to use fsSelection bit 7, that is most likely because your Typo values do not sum to your Win values, i.e. you want to decouple linespacing from clipping. So then you are back at cross-platform compatibility issues.

What causes this behaviour in TextEdit?
The font format is Mac Type 1, generated as a suitcase, with Fontlab.

Metric values are identical for roman and italic — including “BBox” y-axis values, alignment zones, etc., and yet italic characters position lower than roman.

It doesn’t happen in other applications such as CS and Word.

“Metric values are identical for roman and italic — “

Triple checked?

Have you previously installed a different version with the same name? If so, it may be a font cache issue, where the OS is not displaying your most recent version of one of the two fonts.

Nick,

send me the font, I’ll take a look.

General: keep in mind that this stuff is VERY different for OTPS, OTTT and Type 1. Each format has its own peculiarities depending on the system and the app used.

For example, I have found out is that for one font format, I have now forgotten which, one version of InDesign used UPM minus Descender to position the first line of text rather than using Ascender (I think it was OpenType PS and TypoDescender, but am not sure). So if you made Ascender+Descender <> UPM size, the first line was off by a different offset than the rest.

Adam

Nick,

I had the same Problem with two fonts (normal and small-caps) of the same family, the small-caps produced a wider linespacing than the normal weight. All vertical metric values were equal. I think TextEdit does not look at any metric values. It measures the font boundingbox by itself.
The source of the problem was a missing extreme point at the bottom of a cedilla. A BCP-handel was placed far below the descender. After setting the extreme point everything was fine.
I think checking your accents is a good idea.

Eigi

Thanks Andreas, I’ll check those again!

While working on a photofont plugin for AID, QXP and web we have this problem with vertical (and also horizontal) layout of text in a text block. Since from the block that has to be served by plugin we have absolutely no access to any pixel outside it, we have to fit everything inside to avoid any kind of glyph cutting.

Unfortunately it makes impossible typographically correct layout of the text (lsb on the left, ascender or ascender+linegap on the top): what should we do with script-like fonts which extend outside the left margin line? The same problem happens with top layout: in fonts similar to Zapfino Ink many glyphs extend vertically beyound ascender and even UPM line.

So far we found no other solution for the “top-left” problem then using font bounding box - this is the only way to make sure that no part of a glyph will disappear. Unfortunately it makes difficult to align text blocks on the page, requiring some manual control.

Another problem would be to define “typographically correct” font bounding box: some glyphs will never appear as leftmost on a text line (take accents made “old” way with negative left sidebearing) but may have big impact on calculating font bbox. We have no good solution for this right now, but we continue research.

In photofonts detecting glyph (and font) bounding box has additional level of complexity: since glyph image has “smooth” transparency, it is not easy to draw a line of where it actually ends.

Track.

ChrisL

“Track”
Track to the widest bounds of each character proportionally and Lead to the widest the bound of all characters, you mean?

A glyph shape not needing to be a subset of the glyphs ’compose-me-here-without-leading-or-tracking’ box, is in the top 10 highlights of digital type composition, somewhere ;-) So, when one wants to export typography without a good definition of the em, or a format to hold the ’true’ extremes, that is tough.

Nick’s issue, since he’s got one style working, should be solvable by one combination or another of type number monkeying.

But now that this bounding issue is just a stable of variables, I’ll be cool to have a type design app so if the type designer knows the answers, the app knows the questions and can display, (as guidelines), ’the bounds’, when that’s important in a design(er). I don’t think anything does that now, does it?

Cheers!

Thanks, David! That was an insightful explanation which I am glad you posted.

My posting of the word “track” was just my quick way of getting this thread to show up in my list of threads to follow :-/

ChrisL

/track/

without a good definition of the em

It seems to me that Fontlab wimped out on that.
Left and right sidebearings are shown—but “show vertical metrics” doesn’t, other than x-height, cap-height, and ascender-height (unless there is some feature somewhere I’ve missed, that turns on a visual representation of “WinAscent”, “TypoLineGap”, etc).

With Fontographer’s glyph window, as I recall, there was a visual display of the em square—as if it really existed!