[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft] Freetype2 returns different descender value after upgrading 2.6
From: |
선민호 |
Subject: |
Re: [ft] Freetype2 returns different descender value after upgrading 2.6.x to 2.8.x |
Date: |
Mon, 09 Apr 2018 17:46:59 +0900 |
Hello Werner LEMBERG.
Thanks to reply.
Now I can understand why this issue was happend :)
If you don't mind, I have one more question about using glyph height.
We use sum of ascender and descender to determine glyph size is over
winset size or not.
If it is over winset size, we make inner text to "...".
My question is, to determine overflow, which value is most proper
value?
There are many kinds of value which represent "height" in freetype2.
For example, ascender and descender, yMin and yMax, height.
I read documents over and over but it is so hard to say which value is
proper for this.
Could you share your opinion?
Many Thanks,
Minho.
--------- Original Message ---------
Sender : Werner LEMBERG <address@hidden>
Date : 2018-04-06 17:16 (GMT+9)
Title : Re: [ft] Freetype2 returns different descender value after
upgrading 2.6.x to 2.8.x
> After updating, freetype2 returns different descender value when
> using same font.
>
> [...], in 2.6.x, we got 24 as ascender value and -4 as descender
> value.
>
> But in 2.8.x, we got 24 as ascender value and -5 as descender value
> even if using same font file.
>
> [...]
>
> Is it kind of bug?
Yes, but in a reverse way: The FreeType code before 2.8 was buggy.
> I think it should return same value because we use same font.
In such cases you should read the CHANGES file. If you had done that,
you would have found the following.
- Global size metrics values in the `FT_Size_Metrics' structure can
be different for TrueType fonts. Reason is that in older FreeType
versions the metrics were rounded differently to integer pixels
compared to all other font formats, yielding an inconsistent
behaviour if you used non-native hinting. Starting with this
version, global size metrics for TrueType fonts are handled the
same as other font formats: `ascender' gets rounded up,
`descender' gets rounded down, `height' gets normally rounded, and
`max_advance' gets normally rounded, too.
If you need more precise values of (global) ascender, descender,
height, or `max_advance', please take the corresponding values
from the `FT_Face' structure and scale them manually.
I assume that you are using TrueType fonts; the updated documentation
for `FT_Size_Metrics' contains the following.
TrueType fonts with native bytecode hinting
-------------------------------------------
All applications that handle TrueType fonts with native hinting must
be aware that TTFs expect different rounding of vertical font
dimensions. The application has to cater for this, especially if it
wants to rely on a TTF's vertical data (for example, to properly
align box characters vertically).
Only the application knows in advance that it is going to use native
hinting for TTFs! FreeType, on the other hand, selects the hinting
mode not at the time of creating an FT_Size object but much later,
namely while calling FT_Load_Glyph.
Here is some pseudo code that illustrates a possible solution.
font_format = FT_Get_Font_Format( face );
if ( !strcmp( font_format, "TrueType" ) &&
do_native_bytecode_hinting )
{
ascender = ROUND( FT_MulFix( face->ascender,
size_metrics->y_scale ) );
descender = ROUND( FT_MulFix( face->descender,
size_metrics->y_scale ) );
}
else
{
ascender = size_metrics->ascender;
descender = size_metrics->descender;
}
height = size_metrics->height;
max_advance = size_metrics->max_advance;
> And plus, is it possible that the sum of asender and descender is
> bigger than required size?
By default yes, due to ceiling and flooring the vertical dimensions.
See above how to change that specifically for TrueType fonts.
Werner
[cid:cafe_image_0@s-core.co.kr]
[update?userid=minho.sun&do=bWFpbElEPTIwMTgwNDA5MDg0NjU5ZXBjbXMxcDJhMWE
0YTM0Yjc2MGYxM2I2Yzg2YjU3ZmUyZTQxZDg1YiZyZWNpcGllbnRBZGRyZXNzPWZyZWV0eX
BlQG5vbmdudS5vcmc_]