Page 1 of 1

Vertical Metrics bug [Closed]

Posted: Thu Jun 23, 2011 2:19 am
by Timo Kähkönen
There seems to be a problem with vertical metrics in Scanahand 3.1 Premium Edition, Windows 7 Ultimate Edition.

I filled a basic 1-page template ( ... dified.png) with default metrics ( ... terSet.xml) and after generating got a font ( ... mplate.ttf), that has glyphs on wrong vertical position or wrong vertical metrics.

Letters in the generated font are too high (or the vertical metrics in the font are wrong), although they are right on the printed and scanned template images as well as on the program (Template Editor / Advanced Settings / Positioning / Cell Ratios). According to the template, the top point of uppercase letters is approximately on Ascender guide line, and above that line there should be plenty of space (exactly 30% of font height because the distance between Ascender Guide Line and Top line is 30% of cell height). But there is no such space, only about 1% (!) and the font is unusable.

I have no idea why this occurs, but in my thoughts there is no other way to determine font vertical metrics than those ones that are on the printed template and on the program Template Editor. When a user is drawing glyphs on template, he/she draws them according to guide lines. If some letter is drawn on wrong vertical position accidentally, the mistake will (and MUST) remain in the generated font. The Scanahand should not adjust vertical positions at all, because the program cannot know if it is a mistake or not. In my bug example Scanahand has not honored the metrics of the template (24-12-20-14-10), but has made some own assumptions.

This is a clear example, but I made also other tests, and Scanahand always forget the vertical metrics of the template and make some own assumptions that are possibly based on glyph vertical positions (correct me if I'm wrong).

The default metrics has the following values:
Caption 20,00 Top

Top 24
Ascender 12
x-Height 20
Baseline 14
Descender 10

The meaning of these values is not mentioned anywhere in the program GUI or help. I made some tests and figured out that Top, Ascender, x-Height, Baseline and Descender are not guide line positions (as I first thought), but heights of AREAS between guide lines. For example Ascender is in font terminology the distance between Ascender and baseline, but in Scanahand Ascender is the height of area between Ascender-line and x-Height-line. And "height of area" is not absolute value and not percentage of cell height, it is a relative value to the TOTAL SUM of other metrics (TOTAL SUM is height of cell without Caption). For example, if Ascender is 12 and TOTAL SUM of metrics (Top, Ascender, x-Height, Baseline and Descender) is 80, the Ascender is 12/80 = 15 % of cell height without caption.

The definition of metrics seems to be the following:
Top - relative height of area between font top line and Ascender-line (font top line is the bottom line of Caption if Caption is positioned on top of cell, otherwise top of cell)
Ascender - relative height of area between Ascender-line and x-Height-line
x-Height - relative height of area between x-Height-line and Baseline
Baseline - relative height of area between Baseline and Descender
Descender - relative height of area between Descender and font bottom line (font bottom line is the top line of Caption if Caption is positioned on bottom of cell, otherwise bottom of cell)

The minimum value for each metric is 0 and maximum is 1000. "Relative height of area" is relative to the TOTAL SUM of metrics. If all metrics has maximum value 1000, the maximum TOTAL SUM of metrics is 5000. Greater values means greater accuracy. This should be mentioned in help.

Re: Vertical Metrics bug

Posted: Thu Jun 23, 2011 7:29 am
by Erwin Denissen
The part of the manual related to the Template Editor says this about the Advanced Positioning Settings:
Change page and cell header size and guide line positions
I agree the manual can be further improved, but the main assumption is mentioned here:
Whatever changes you make, do make sure the baseline is positioned correctly, as that position is used to determine the vertical position of your characters.
To clarify this, this is the only metric that is used. The others are used to position the horizontal guide lines (the little marks on both left and right side of each cell) and are only there for your convenience while drawing the characters.

During the generation of the font, Scanahand will calculate the optimized values for the metrics. The top and bottom of the individual characters are part of the math, so for example if you have one or more tall characters, the Ascender metric will increase as well.

Re: Vertical Metrics bug

Posted: Thu Jun 23, 2011 3:22 pm
by Timo Kähkönen
The top and bottom of the individual characters are part of the math, so for example if you have one or more tall characters, the Ascender metric will increase as well.
When the calculation of metrics ( ... natomy.png) is made by the way Erwin described (using actual glyphs), user have to draw at least (correct me if this is wrong):
- one uppercase letter (A) to get the Cap Height
- one lowercase (a) to get the x-Height
- one lowercase with ascender (k) to get Ascender
- one lowercase with descender (j) to get Descender

This is clear and user usually draws those letters. But there are missing (Win)Ascent and (Win)Descent. These determine (I suppose) the upper and lower bounding of the font. How these are calculated in Scanahand?

Is the baseline got from scanned template image (capturing those little marks on both left and right side of one cell) or from program's template settings? How the baseline position is calculated?

I assume the following and correct me if this is wrong:

- White margins of template page bitmap image are stripped and the height of stripped page is calculated, for example 2000 px
- Top header is removed. If height of top header is 1 and the rest is 15, the height of rest is 15 / (1+15) * 2000 px = 1875 px
- Cell height is calculated. If there are 11 rows, then the cell height is 1875 px / 11 = 170.45 px
- If Caption is positioned on the top of cell, we subtract caption's height from cell height 170.45 px - 20,00 % * 170.45 px = 136.36 px which is the height of Glyph Area
- Baseline position is got by calculating (Ascender + Descender) / TOTAL SUM of metrics * height of Glyph Area = (14 + 10) / 80 * 136.36 px = 40.91 px
- Now we know that the baseline position is at the height of 40.91px from the bottom of the Glyph Area.

Re: Vertical Metrics bug

Posted: Fri Jun 24, 2011 6:59 am
by Erwin Denissen
Your assumptions are mostly wrong.

The algorithm that calculates the metrics is not something that a regular user of Scanahand should worry about. Maybe if we better understand your main concern with the metrics, we might be able to help there.

Re: Vertical Metrics bug

Posted: Fri Jul 01, 2011 1:00 pm
by Timo Kähkönen
The main concern is: how to be sure, that the generated font is as high as other font? If I have an existing font (that is created with Scanahand or with some other tool) and I want to make other font that is identical sized, which means that for example 12pt letter 'A' has same height in both fonts. The workflow is this: I print sample letters on template using existing font and draw chars on this template. This is why the metrics calculation principles has to be explicitly mentioned somewhere in the documentation. According to my tests chars of font generated by Scanahand are higher than those that are printed on template cell.

Re: Vertical Metrics bug

Posted: Fri Jul 01, 2011 1:21 pm
by Erwin Denissen
Since each font is different, each font will have different metrics. That (calculation of metrics) is done by design.

Re: Vertical Metrics bug

Posted: Sat Jul 02, 2011 12:09 am
by Timo Kähkönen
I have feeling that my issue is misunderstood.

Lets try again:
I have Font1, which is made with some other tool than Scanahand. I want to make italic version of it by drawing characters on template with italic style. I want that my 12pt uppercase letters in Font2 are exactly as high as 12pt uppercase letters in Font1. To get the same size and feeling across family, I print characters of existing Font1 as samples in template. The problem is now to determine the right size of sample characters. It seems that characters of Font2 becomes much larger than characters of Font1. How to get the size of both fonts to be same?

Because the fonts will be same family, the size, metrics and linespacing have to be (roughly) same.