We use FC for analyzing and fixing fonts - we don’t create new ones.
Our application reads fonts using the freetype library. The goal of reading font files is to create the shape of a text exactly like another (windows) application does.
The attributes of the text are mainly the font name and the text size which is given in metric units.
Our problem is, that we do not fully understand which font metrics are used to calculate the size of the text shape that we try to mimic.
A font e.g. has the following metrics when we open the Font Settings → Metrics tab:
We do not understand, although we read the docs, which values are read from the font file and which ones are calculated and how?
The doc says that the Win Ascent and Win descent values are calculated. In the above font we can read an ascender value of 743, but if we use this as the base value our character shapes are somewhat too small. So we assume we would have to take a value of about 700 which is shown in the Typo Ascender value. This value however is apparently (?) not saved into the font file.
So the first question is: How is this value calculated?
The next thing that we do not understand is what the Calculate button does. The doc simply says that is calculates the ascender and descender values. But which ones and how?
When we hit the button the metrics for the above font change to:
We see that the Typo … values have changed. But if they are calculated which values are used before we use the Calculate button? And are these values stored into the font and do you know under which values can they be accessed with the freetype library? And what is the differerence between the Default and the Maximum settings for the Calculate function?
The application whose behaviour we try to mimic does not change the shape of the text if we change one of those ascender values so we assume is does the calculation on the fly like the Calculate function does.
The doc also says that the Win Ascent value is calculated for all characters in the ANSI character set. Do you mean ASCII character set (ASCII value 1-127) or extended ASCII (1-256) or what?
All editable fields are stored into the font file, but you can use the Calculate button to let FontCreator do the math so the values best represent the description from the font specifications. Feel free to change the values, if that leads to better results with freetype.
Well, changing those values does help our application, but the problem is that the other application does not take into account those ‘fixed’ values rather than calculating it on the fly. To mimic that behaviour, out application would have to do the same calculation as well.
So the question is:
Is the calculation that FC does when I hit the Calculate button specified by the true or open type specification or can you tell us, what precisely is calculated by that function?
I really don’t understand your last post. You can change the values either manual or through the Calculate button.
Maybe it helps if you remove the Vertical device metrics (VDMX) table. Or if it doesn’t exist it might help if you generate this table. You can use a utility from Microsoft called CacheTT, located at: http://www.microsoft.com/typography/tools/tools.htm
Hi Thomas, I’m no expert but if I understand you corectly you want to know the end results of changing certain values using FC.
If you make those changes and save the font (hopefully under a new file name) those values become an integral part of the font.
Any application using the new font will recognize and use those new values to determine how many pixels tall or wide the glyphs are … or if the glyphs extend beyond Win Ascent or descent, where the glyphs will be cut off, and what the spacing between glyphs will be.
Those calculations are applied to every glyph in the font.
I seem to remember reading in a post in the Unicode mailing list some years ago, details of the list and its archives at the the http://www.unicode.org webspace, that Microsoft build into their software that when loading a font some of the parameters are calculated from some of the data rather than relying upon the values stated in the font. It may have been something like calculating the maximum ascender and descender values from the data of the glyphs rather than relying upon what the font supplies as the values. Anyway, the person posting the comment was from Microsoft and said that they felt that they had to do that because so many fonts that were around at the time had the wrong data in them and that was the way to get the fonts to display properly. Thus there exists the possibility that whatever figures someone puts into the font, it may possibly be that the Microsoft system is ignoring them and calculating the figures which it uses by some different algorithm.
I am not seeking to criticise Microsoft over this: I have known times when Windows 98 displayed things like a grave accent over a letter e properly even when I had got the contour going in the wrong direction, displaying properly possibly due to that sort of protective action when loading the font!
I just mention it though just in case Windows is doing things in its own way regardless of what values are put in the font, thus making trying to produce the same look in another system a problem unless one knows the method that Windows is using to compute the parameter values which it then uses.
I do not know how to resolve the situation, yet perhaps the above might be a clue as to why the problems are being observed.
However, it might not be about what was in that remembered post at all, yet I just mention it in case it is.
I know some applications use the Line Gap value while others ignore it. For example Microsoft Word uses this value, Notepad ignores it.
You can test this by significantly increasing the Line Gap value as you will see the distance between two lines of text is increased in applications that make use of this value.
We get some more insight in the problem now. We now understand how the load the OS2 table with freetype and at least have the access to the mentioned metric values.
Williams reply is mostly what we fear, that the used values are not the ones from the font file. And as it is publicly not known how Microsoft or any other application(?) calculates the ascender (and other?) values we are somewhat stuck. So somehow we have to “reverse engineer” that calculation by changing values and measure the effect.
All that I learn about fonts I have the impression that reproducing identical text aspect in different application is quite tricky (if possible at all?).
Hello, forgive me if I get this wrong, it is the first time I have ever posted on a bulletin board. I read this topic with interest, but didn’t quite get what I’m looking for here. I am really very confused about the various ascender and descender options in FC. When I open a new document I note that Win Ascent/Descent are set at different heights to Typo Ascender/Descender, and in the metrics panel the Ascender/Descender values are also sometimes different. I understand that these are all ‘different’ things, but why are they by default set at different values. Which one is most important for getting a font to work, and what happens if they are all set to the same value? I’m also curious about the line space setting which I also haven’t quite got my head around. What perplexes me most is that I am a trained typographer (although trained a long time ago) and I fully expected to understand these technicalities, but it seems the intrusion of the dreaded PC has altered the terminology of my beloved typography.
They are different measurements used by MAC and Windows.
To get a font to work, just select “Maximum” and click on “Calculate.”
Any glyphs that cross the WinAscent or WinDesent lines will be clipped. If you have problems with some glyphs. Double-click in the Font Properties windows to locate the glyphs with Y Max and Y Min values.
