it’s not really the same as the ascent. Some of my fonts were getting cropped by this. instead i made this function virtual so i can provide the ascent ratio in `setCharacteristics’ but return the ascent multiplied by a dpi factor for getHeightToPointsFactor, since this function needs to take into account the dpi.
?
Is that on windows?
The juce font height is in pixels, so for the typeface it only needs to tell juce a normalised scale or generally to scale the glyphs by the max size box and then juce can scale up or down accordingly.
however, if you want to work in point sizes - and this is useful because point sizes are physical onscreen sizes 72 being 1 inch high on your monitor or on your phone regardless of DPI, juce will somehow have to know the scale factor between point sizes and pixels sizes. This is precisely what CustomTypeface::getHeightToPointsFactor does.
However, the ascent ratio (ie the ascent / max height) does not take into account dpi. the appropriate scaling will depend on your OS. so this value is not the correct one for this function.
For example, using freetype under windows, i found i had to multiply the factor above by 0.72 (suspicious number?). The only way to do this in a custom font is to give the scaled version of the ascent ratio in `setCharacteristics’. This appeared to work for most fonts, until i tried some fancy ones. These wound up being drawn too high, clipped at the top and wasted space underneath. This was due to me giving the wrong value for the ascent.
To fix this i give the correct ascent ratio in setCharacteristics (ie ascent/height) then give ascentRatio * 0.72 (windows example) on my version of CustomTypeface::getHeightToPointsFactor which i had to make virtual and override.
In general, i don’t think it needs to be custom, but does need to use the DPI. However, i dont have a general formula for the correction yet. but the DPI will be used there somewhere and, AFAIK its not taken account of anywhere in juce, which means it’s only working by luck.
Patrick can you please weigh in on this?
I agree with hugh, that when converting from points to pixel the dpi needs to be taken into account. Freetype does this in the FT_Set_Char_Size function:
[quote]error = FT_Set_Char_Size(
face, /* handle to face object /
0, / char_width in 1/64th of points /
1664, /* char_height in 1/64th of points /
300, / horizontal device resolution /
300 ); / vertical device resolution */[/quote]
In JUCE win32 it seems this is hard coded to 72dpi in WindowsDirectWriteTypeface:
heightToPointsFactor = (72.0f / GetDeviceCaps (tempDC, LOGPIXELSY)) * unitsToHeightScaleFactor;
In JUCE mac it seems fonts are created using operating system calls that take point sizes and the OS will therefore take the DPI into account automatically. For example in juce_mac_Fonts.mm :
If my findings are correct mac works correctly already and the correct fix in win32 would be to the take the real dpi into account in the line above where the heightToPointsFactor is calculated.
FWIW, Jules has commited a patch where it now uses the real DPI on Windows.
No longer hardcoded to 72