Typophile - WinAscent... LineGap... Font BBox? - Comments

without a good definition of

Nick Shinn — Mon, 17 Dec 2007 09:42:53 -0800

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!

/track/

Goran Soderstrom — Mon, 17 Dec 2007 02:01:02 -0800

/track/

Thanks, David! That was an

dezcom — Thu, 13 Dec 2007 11:15:20 -0800

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” Track to the

dberlow — Thu, 13 Dec 2007 07:30:36 -0800

“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!

Track. ChrisL

dezcom — Thu, 13 Dec 2007 06:28:09 -0800

Track.

ChrisL

While working on a photofont

yuri — Thu, 13 Dec 2007 03:25:43 -0800

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.

Thanks Andreas, I’ll check

Nick Shinn — Tue, 4 Dec 2007 11:58:10 -0800

Thanks Andreas, I’ll check those again!

Nick, I had the same Problem

eigi — Tue, 4 Dec 2007 09:08:07 -0800

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

Nick, send me the font,

twardoch — Sat, 1 Dec 2007 23:05:39 -0800

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

Have you previously

Mark Simonson — Fri, 30 Nov 2007 06:08:55 -0800

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.

“Metric values are

dberlow — Fri, 30 Nov 2007 05:18:47 -0800

“Metric values are identical for roman and italic — “

Triple checked?

What causes this behaviour

Nick Shinn — Fri, 30 Nov 2007 01:53:38 -0800

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.

What Read Roberts found on

John Hudson — Tue, 20 Nov 2007 19:59:01 -0800

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.

“How do you adjust the em

dberlow — Sun, 18 Nov 2007 05:44:41 -0800

“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!

How do you adjust the em

Mike Jarboe — Sat, 17 Nov 2007 22:54:39 -0800

How do you adjust the em square?

WinAscent... LineGap... Font BBox?

Nick Shinn — Fri, 16 Nov 2007 19:33:42 -0800

What is it that causes the positioning of fonts relative to the top of a text box?