Font metrics units

[Ben Mewburn - ReNet.com.au]

Output of calls to the various metrics of the Courier font in Haru:

Ascent: 629, Descent: -157, X-height: 426, Cap-height: 562

Are these units thousandths of a pt? Or something else?

[Bill Horger]

What did you set the font height to be, originally? If you did not set the height (in points), then the units are meaningless.

Bill

--
--
---
libHaru.org development mailing list
To unsubscribe, send email to libharu-u...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "libHaru" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libharu+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Mewburn - ReNet.com.au]

I didn't set the font size to anything. I should specify that these values were obtained using the HPDF_font_* functions. The only place I see to set the font size is on the page. Surely calling HPDF_Font_GetAscent() returns values that are not relative to the current size set on the page? 

[Bill Horger]

Ben,

You are correct. Setting the font parameters has no effect on the numbers returned these numbers are specific to the font being used.

From what I can find, these values are unitless UNTIL they are applied to the font size used. The numbers are usually given in UPM (units per eM) and, generally, a font will have a UPM that is a power of 2 (see this reference for more details) but that is not a requirement. Without knowing under what UPM the font is defined to be, the actual numbers given are not precisely useful, but still can be used. The emphasis on precisely is because the base UPM is unknown.

And, the line spacing parameter is undefined in libharu (although it might be determinable; I am not a font design expert). There is a HPDF_Page_SetTextLeading function() call and HPDF_Page_GetTextLeading(), but I can't find it documented in the Wiki. The references I found were in the code samples, and they did not reference a specific font in the function calls.

Perhaps this link will also help: http://encyclopedia2.thefreedictionary.com/Descent+%28font%29

Line-to-line spacing is defined by the leading parameter (pronounced "ledding" from the days when the element lead was use to make fonts), which you have to accommodate when outputting your lines of text (not automatic in libharu, but this is a guess). One of the examples I have seen is for a 12 point Courier font, the leading was 15 points.

Specifically: For my application, the text size is specified in inches (0.18) which is 12.95993 points, and I'm using the same font as you are using. Since the baseline is used to determine the sign of the descender, we subtract the descender to get the total, which is defined at the same as the font size.

Using the definition from the link above, the 12.95993 = X * (629+426-(-157)) == X * 1212. Note that the "1212" value that is computed is not a power of 2, but that is not a requirement per the font standards.

Solving for X yields X=0.0106. Using this value, I can now crunch the text as tight as I wish at this "X" value point size by using this factor for my 12.95993 font.

Could I have done my crunching/spacing/etc. without the computation using the values from ascent etc.? Yes.

Bill

[Ben Mewburn - ReNet.com.au]

Thanks for your help, Bill.

I've looked at the links and since scoured the net for more info. A few sources have suggested that the font UPM for built in fonts is 1000. I've crossed checked with another pdf lib which has a 'getUnitsPerEm' function and I get the same values for ascent, descent etc as in libharu for the built in fonts with the font UPM being 1000. So getting the ascent, descent, other fontMetric etc in pt should be just x = size * fontMetric / 1000.

However, as you point (pun intended) out fonts may not necessarily be defined in 1000 UPM space (ttf etc). So does haru normalise loaded fonts to 1000 UMP? Or is haru in need of a HPDF_font_getUMP() function? For now I'm using the value of 1000 and will see how it goes.

[Bill Horger]

Well, now I'm curious! What is driving the need for all of these parameters?

It may not be accurate to use 1000. The "standard" would imply 1024 would be a better choice (2^10). Whether it matters certainly depends upon your usage.

For one of my applications (lots of text), I used 12 point Courier as the standard and adjusted the leading from as low as 13 point (way too close) to as much as 16 point (way too much space), and settled, experimentally, on the 15 point "standard" for lead typeface. Since my text was actually tabular data, not separated by lines, the row spacing is important to allow the user to read the columns more readily.

I, too, wish there was a "leading" parameter available, in UMP, for a given font. It would appear that the Windows font support system calls allow one to query this parameter.

Please do let me know your application need for these parameters. Maybe I'm missing something, and I love to learn!

Bill

[Ben Mewburn - ReNet.com.au]

It's for a document builder api. In this particular case I have a multiple line text box object that can contain text in different fonts. I need to be able to calculate the space taken up by the different fonts for layout and rendering. Perhaps there is an easier way than delving into font UPM, descent ascent etc but the api is largely written and I'm switching out the underlying pdf library.

[Bill Horger]

Ben,

Thanks! Always illuminating to hear what others are doing.

Bill