Fallback font is rendering glyphs taller than primary font?


Hi Jules,

I have a funny case - I am setting a label to be the height of my font, and it’s bordersize to 0,0. When I render the label in Asian languages, which use the fallback font, I noticed that some of the glyphs seem to be getting cut off on the top. It seems that the height of the glyphs in the fallback font is greater than the max height of my original font. I’ve verified this seems to be what is happening.

I next tried just using my CJK font as my primary font when I know I’m going to be rendoring CJK text, but that had it’s own problems and opens a whole other can of worms (my graphic designer is not going to be happy when he sees the English text that is rendered with the CJK font, and it creates a bunch of other work for us in fixing layout issues caused by this).

Can you think of an easy way to determine the height of the actual rendered string so that I can set my label height correctly? The best I can come up with would be to create a font based on the fallback font name, set it to the height of my original font, and then ask the fallback font for it’s height. It seems like a tautology. I feel like there must be something simpler (not opposed to patching Juce sources if that is the best way). My biggest confusion is why/how the fallback font is rendoring larger than the original though.

Anyway, any ideas? Also, While we’re on the topic, I’ve noticed that the fallback font does not honor bold, or does not seem to. Would this be an easy fix?



Which juce version is this…?



I realized that I am likely incorrect about Juce not honoring bold. We’re using a bold typeface that is bolded in the original glyphs and that we’ve embedded as a resource, so we haven’t actually told Juce that the typeface is bold.

The glyph height is, I’m quite certain, too large in the fallback font though.



In case it’s helpful here are some of the fallback font’s we’re using on OS X:
Language Tag – Font

zh_CN – STHeiti
zh_TW – LiHei Pro
zh_HK – LiHei Pro
ko – AppleGothic
ja – Hiragino Kaku Gothic Pro
I know I’ve seen the problem on simplified Chinese, which is using LiHei Pro


The font code has all completely changed since 1.50 - there’s no point in me looking into this bug, because I can’t do anything about it in the old code, sorry!


Is the tip stable? 1.50 is still what sourceforge claims is the latest “release”. Should I be nervous to move a nearly shipping project up to the tip?


I’m currently stabilising the tip, ready for a new release shortly, so it’s pretty good at the moment.