Re: [ft-devel] truetype metrics resize request question
Werner, you are right, it should be reflected in the CHANGES. The changes result in better, more consistent line spacing. DejaVu got one point smaller, there is nothing wrong with that too. Done. Thanks for the images! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
For reference if anyone is curious, any pixel size that is not a multiple of 5 will exhibit the problem. A couple common ones are 72px and 96px which should be a 72x72 and 96x96 respectively. Leading is 0 for Ahem so height should be ascent+descent. $BUU$(Q.-(B I've applied your patch. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've made a patch for the proposed change below. Please let me know if anything needs to be adjusted. The patch looks good, thanks. Just for the record, please give some numeric values for your problem with the Ahem font so that I can identify and handle potential issues in the future more easily. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
For reference if anyone is curious, any pixel size that is not a multiple of 5 will exhibit the problem. A couple common ones are 72px and 96px which should be a 72x72 and 96x96 respectively. Leading is 0 for Ahem so height should be ascent+descent. 72px Before Ascender: 3712 Descender: -960 Height: 4672 == 73px After Ascender: 3712 Descender: -896 Height: 4608 == 72px 96px Before Ascender: 4928 Descender: -1280 Height: 6208 == 97px After Ascender: 4928 Descender: -1216 Height: 6144 == 96px I've made a patch for the proposed change below. Please let me know if anything needs to be adjusted. The patch looks good, thanks. Just for the record, please give some numeric values for your problem with the Ahem font so that I can identify and handle potential issues in the future more easily. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've made a patch for the proposed change below. Please let me know
if anything needs to be adjusted.
Thanks!
On Mon, Jul 11, 2011 at 8:07 PM, Steven Chu steven.f@gmail.com wrote:
To clarify what I've observed with the Ahem font:
From ttdriver.c:
static FT_Error
tt_size_request( FT_Size size,
FT_Size_Request req )
{
/* Current value for size == previous calculated metrics */
TT_Size ttsize = (TT_Size)size;
FT_Error error = TT_Err_Ok;
#ifdef TT_CONFIG_OPTION_EMBEDDED_BITMAPS
...
#endif /* TT_CONFIG_OPTION_EMBEDDED_BITMAPS */
FT_Request_Metrics( size-face, req ); /* Calculates new metrics,
incorrect for Ahem */
if ( FT_IS_SCALABLE( size-face ) ) /* Ahem is scalable */
error = tt_size_reset( ttsize ); /* Calculates proper metrics
stored in ttsize */
/* ttsize-metrics contains proper metrics, size-metrics contains
incorrect metrics */
return error;
}
and my proposed change:
tt_size_request( FT_Size size,
FT_Size_Request req )
{
...
if ( FT_IS_SCALABLE( size-face ) )
{
error = tt_size_reset( ttsize );
/* Fix: copy reset metrics from TT_Size to publically accessible
FT_Size metrics */
ttsize-root.metrics = ttsize-metrics;
}
return error;
}
From 79d31e49a9f576de38d7298f30aa2c937ace7522 Mon Sep 17 00:00:00 2001
From: Steven Chu steven.f@gmail.com
Date: Wed, 13 Jul 2011 19:54:57 -0500
Subject: [PATCH] [truetype] Fix metrics on size request for scalable fonts.
* src/truetype/ttdriver.c (tt_size_request):
Fix copying metrics from TT_Size to FT_Size if scalable font.
---
ChangeLog |7 +++
src/truetype/ttdriver.c |3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f2b8365..59680c6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2011-07-13 Steven Chu steven.f@gmail.com
+
+ [truetype] Fix metrics on size request for scalable fonts.
+
+ * src/truetype/ttdriver.c (tt_size_request):
+ Fix copying metrics from TT_Size to FT_Size if scalable font.
+
2011-07-10 Алексей Подтележников apodt...@gmail.com
[psaux] Optimize previous commit.
diff --git a/src/truetype/ttdriver.c b/src/truetype/ttdriver.c
index 66061fd..e70a611 100644
--- a/src/truetype/ttdriver.c
+++ b/src/truetype/ttdriver.c
@@ -246,7 +246,10 @@
FT_Request_Metrics( size-face, req );
if ( FT_IS_SCALABLE( size-face ) )
+{
error = tt_size_reset( ttsize );
+ ttsize-root.metrics = ttsize-metrics;
+}
return error;
}
--
1.7.4.1
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've been working on a bug for webkit related to an odd behavior with the Ahem font in the Qt framework. I tracked it down to Qt either receiving incorrect descent/ascent values from FT_Size_Metrics or using the Freetype library incorrectly. When using FT_Set_Char_Size(face, width, height, h_res, v_res), should face-size-metrics have the proper values for all font types afterwards or is it necessary for Qt to handle knowing truetype fonts use ((TT_Size)face-size)-root.metrics instead? BTW, right after a call to FT_Set_Char_Size, `face-size-metrics' and `(TT_Size)face-size)-root.metrics' point to the same object... You probably mean something different? If face-size-metrics is supposed to have proper values after calling FT_Set_Char_Size, then there is a bug in either ttdriver.c or ttobjs.c. ttdriver.c line 248: if ( FT_IS_SCALABLE( size-face ) ) error = tt_size_reset( ttsize ); will need to copy ttsize-metrics over to ttsize-root.metrics or ttobjs.c line 1057: metrics = size-metrics; will need to be metrics = size-root.metrics; are some potential fixes. This is a difficult issue. The question is what `proper values' actually mean. From the documentation for FT_Size_Metrics: Note that due to glyph hinting, these values might not be exact for certain fonts. Thus they must be treated as unreliable with an error margin of at least one pixel! Normally, FreeType does grid-fitting of metrics (cf. the stuff guarded by the GRID_FIT_METRICS macro in ftobjs.c's ft_recompute_scaled_metrics) using FLOOR and CEIL if hinting is requested for, regardless of the font format. For TrueType fonts, this gets replaced internally with ROUND if the font asks for it (in tt_size_reset). This explains the one-pixel difference you experience sometimes. Mhmm. Perhaps the rounding code in `tt_size_reset' should be executed only if GRID_FIT_METRICS is undefined? The metrics values actually *are* already rounded to integers... Chia-I, can you comment also? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] truetype metrics resize request question
I've been working on a bug for webkit related to an odd behavior with the Ahem font in the Qt framework. I tracked it down to Qt either receiving incorrect descent/ascent values from FT_Size_Metrics or using the Freetype library incorrectly. When using FT_Set_Char_Size(face, width, height, h_res, v_res), should face-size-metrics have the proper values for all font types afterwards or is it necessary for Qt to handle knowing truetype fonts use ((TT_Size)face-size)-root.metrics instead? If face-size-metrics is supposed to have proper values after calling FT_Set_Char_Size, then there is a bug in either ttdriver.c or ttobjs.c. ttdriver.c line 248: if ( FT_IS_SCALABLE( size-face ) ) error = tt_size_reset( ttsize ); will need to copy ttsize-metrics over to ttsize-root.metrics or ttobjs.c line 1057: metrics = size-metrics; will need to be metrics = size-root.metrics; are some potential fixes. Thanks, Steve ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] truetype metrics resize request question
I've been working on a bug for webkit related to an odd behavior with the Ahem font in the Qt framework. I tracked it down to Qt either receiving incorrect descent/ascent values from FT_Size_Metrics or using the Freetype library incorrectly. Within TrueType fonts, there are three sets of global descent/ascent values for historical reasons. Normally, FreeType uses the ascender/descender values from the `hhea' table; this seems to work in most cases. However, the `OS/2' table holds two other sets, and it is easily possible that your font contains strange values within `hhea'. A few days ago I've applied a patch which makes FreeType use the values from `OS/2' in case the `hhea' values are both zero. When using FT_Set_Char_Size(face, width, height, h_res, v_res), should face-size-metrics have the proper values for all font types afterwards or is it necessary for Qt to handle knowing truetype fonts use ((TT_Size)face-size)-root.metrics instead? The former. But due to the problematic definition of the global ascender and descender in TTFs, FreeType might give wrong results. If face-size-metrics is supposed to have proper values after calling FT_Set_Char_Size, then there is a bug in either ttdriver.c or ttobjs.c. ttdriver.c line 248: if ( FT_IS_SCALABLE( size-face ) ) error = tt_size_reset( ttsize ); will need to copy ttsize-metrics over to ttsize-root.metrics or ttobjs.c line 1057: metrics = size-metrics; will need to be metrics = size-root.metrics; are some potential fixes. IIRC, we had such code a few years ago, and it has been reverted for reasons I currently don't remember. Can you privately send me the problematic font for further investigation? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
