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.