freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freetype] Line space calculation in FT 1


From: Antoine Leca
Subject: Re: [Freetype] Line space calculation in FT 1
Date: Thu, 22 Apr 2004 20:46:30 +0200

On Thursday, April 22, 2004 5:00 PM
Rob Kramer <address@hidden> va escriure:

> On Thursday 22 April 2004 05:48 pm, Antoine Leca wrote:
>> FT1 is Truetype only. Hence baseline distance is much easier to sort
>> out, there is less possible variation.
>
> "easy" isn't the word I would use, seeing what follows. :)

Well, then do not think what may happen if you add the other font formats...


> Does FT2 take care of this sort of rather horrible calculations?

No idea. Anyone?


>> prop->os2->sTypoAscender - prop->os2->sTypoDescender +
>> prop->os2->sTypoLineGap
>
>> However, for reasons known only to themselves, Windows designers did
>> use a formula a bit more complex:
>> <CITE>
>> prop->os2->usWinAscent + prop->os2->usWinDescent
>>     + MAX(0, prop->os2->sTypoLineGap
>>         - ((prop->os2->usWinAscent + prop->os2->usWinDescent)
>>             - (prop->horizontal->Ascender -
>> prop->horizontal->Descender))) </CITE>
>
> So, I should always use the latter formula?

If you want to mimic Windows behaviour, yes.

Otherwise, probably not. It might be wise (since it is done this way to
avoid pathologic fonts), but YMMV.



>> Beware on the units: os2 fields are integers, horizontal ones are
>> fixed-point!
>
> If that's the case, how come the values are the same as in os2?

Sorry, my mistake. Misreading the specs. One says FWORD (signed 16-bit count
of units in the em space), while the other says SHORT (signed 16-bit random
quantity, which in this case happens to be... units in the em space).
Bummer.


> Does the horizontal.Version == 0xffff mean it's not valid perhaps?

Yes, that is the convention. It happens with old Apple fonts (say, extracted
from System 6.0.7).


> For the sake of a little experiment, let's use these values to
> calculate the BTBD:
>
> external leading = max (0, 85 - ((1191 + 506) - (935 + 200))) = 0.
>
> BTBD = 1191 + 506 + 0 = 1697
>
> Is that correct? To me it feels dodgy that the external leading is
> zero..

That is just a way to see it.
The "real" leading is the space between the descent of the upper line (lower
part of pqg etc.), and the ascent of the caps or of the tall letters (lf).
This is where the accents are.

Since the Windows view of ascent is different (coming from previous days, it
accounts for some accents, and includes the "internal leading"), what is
left is called "external leading", and does not have any reality outside
Windows: it is purely conventional. And yes, it results quite often to be 0.


> How do I convert the 1697 to a number of pixels?

As with any quantity: dividing with EM and multiplying the point size
(really the other way ;-)).


>> When there is no OS/2 table (prop->os2->version == 0xFFFF), or when
>> only the original OS/2-flavour is available (68-byte format; they
>> are not handled correctly by FreeType; since nobody asks, this is
>> not a problem in practice), the only remaining way is the
>> traditional Apple one,
>
> How would one know if it's an original OS/2 flavoured table?

*You* cannot. *I* can (because inside the library, I know the size of the
tables; the original OS/2 table was 68-byte long, while the Windows 1.50 one
is 78-byte long, but is still tagged 0; since we followed Windows specs, we
always load 78 bytes; since nobody ever complained, we have to assume that
no fonts with 68-byte table remain in use ;-)).
And this is really a quirk (read bug if you want) of Freetype 1.x. But I do
not care correct it right now, until I do the equivalent correction in
Freetype 2 ;-)



Antoine







reply via email to

[Prev in Thread] Current Thread [Next in Thread]