[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