[squeak-dev] Q: Is it all right for TTCfonts to have non-integer heights?
Hi Yoshiki,
Thank you for repling.
Yoshiki Ohshima yoshiki at vpri.org Mon Jul 28 17:48:52 UTC 2008
At Fri, 25 Jul 2008 10:17:27 -0700 (PDT), Jerome Peace wrote:
Q: Is it all right for TTCfonts to have non-integer heights?
Hi all,
Several TTCfonts return float fractions when asked for heights (basically any with a point size not divisible by 3). You can see this by using the World>appearence>system fonts>demo mode and then ...>print default fonts.
Is this a bug?
In the Squeak world, it is ok if it works^^;
I know. But I doesn't quite. TTCFont>>ascent has a code hole that leads to infinite recursion under certain conditions. There are several different versions of TTCFont>>ascent. AFAIK all the ones currently in use including oplc/3.8 have this property. Ralph Johnson patched around this in 3.10. To prevent the certain condition, fallback fonts are limited to strikefonts. IMO this is unsatisfactory and undesirable.
The general problem lies in the developers of TTCFonts not being aware of implict assumptions underlying Strikefonts and font sets. Indeed, I've only become aware of them because I am bug tracking.
Unfortunately, I start with minimal knowledge of how the font stuff works and interacts with the drawing stuff. I am becoming aware of a need for the knowledge of how everything interacts and works together.
My question here comes from an impression from reading the code that some of it assumes heights come in interger pixels. TTCFonts break this assumption.
So either the assumption is incorrect and all the down stream code handles the fractional pixel height with grace or it doesn't. In which case I might find another unobvious bug that under the right conditions crashes the system by running it out of memory.
So if you could give this matter a little more serious thought and help my quest for understanding with a clue or two? It would be appreciated.
Thank you for considering this.
There isn't a real harm with it. There will be some truncation for example for advanced width so the rendered result is in theory not optimal in some cases.
I am concerned here about "height" not width. Do you know where the truncation takes place? Where should I look for it?
Yours in curiosity and service, --Jerome Peace
also see mantis: A Mother for font and font test problems http://bugs.squeak.org/view.php?id=6570