Re: [ft-devel] Severe rendering bug
On 01/02/2012 10:40 PM, Werner LEMBERG wrote:
Looking at the Freetype TrueType interpreter implementation, the
projection vector is in pixel space, meaning that the 300%
horizontal stretch that I use in my example has been applied.
The problem is that in Ins_IP, the projections are calculated using
orus coordinate vectors, which are in em-space (NOT stretched).
If I change from using orus to org, the instruction behaves as I
would expect it to from reading the TrueType specification, and
there are no artefacts.
Can you prepare a patch, please? I currently don't have the time to
really delve into this issue, but maybe `orus' is correct, but should
be scaled properly...
The difference between org and orus is that org has rounding errors
caused by the scaling to 26.6 fixed point pixel coordinates, so scaling
orus seems to be more correct, although I struggle to see how it could
matter in practice. But since the rest of the code really likes to use
orus, it's best to keep using it in IP as well I suppose.
The attached patch fixes the bug, and does not change the case where
x_scale and y_scale are equal, so it should be quite safe and not
introduce any new bugs.
Please review this patch and consider it for inclusion in the next
release of Freetype.
/Tobias
diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c
index c62c589..0041360 100644
--- a/src/truetype/ttinterp.c
+++ b/src/truetype/ttinterp.c
@@ -6575,9 +6575,19 @@
if ( twilight )
old_range = CUR_Func_dualproj( CUR.zp1.org[CUR.GS.rp2],
orus_base );
- else
+ else if ( CUR.metrics.x_scale == CUR.metrics.y_scale )
old_range = CUR_Func_dualproj( CUR.zp1.orus[CUR.GS.rp2],
orus_base );
+ else
+ {
+FT_Vector vec;
+
+vec.x = TT_MULFIX( CUR.zp1.orus[CUR.GS.rp2].x - orus_base-x,
+ CUR.metrics.x_scale );
+vec.y = TT_MULFIX( CUR.zp1.orus[CUR.GS.rp2].y - orus_base-y,
+ CUR.metrics.y_scale );
+old_range = CUR_fast_dualproj( vec );
+ }
cur_range = CUR_Func_project ( CUR.zp1.cur[CUR.GS.rp2], cur_base );
}
@@ -6601,8 +6611,18 @@
if ( twilight )
org_dist = CUR_Func_dualproj( CUR.zp2.org[point], orus_base );
- else
+ else if ( CUR.metrics.x_scale == CUR.metrics.y_scale )
org_dist = CUR_Func_dualproj( CUR.zp2.orus[point], orus_base );
+ else
+ {
+FT_Vector vec;
+
+vec.x = TT_MULFIX( CUR.zp2.orus[point].x - orus_base-x,
+ CUR.metrics.x_scale );
+vec.y = TT_MULFIX( CUR.zp2.orus[point].y - orus_base-y,
+ CUR.metrics.y_scale );
+org_dist = CUR_fast_dualproj( vec );
+ }
cur_dist = CUR_Func_project ( CUR.zp2.cur[point], cur_base );
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Severe rendering bug
The difference between org and orus is that org has rounding errors caused by the scaling to 26.6 fixed point pixel coordinates, so scaling orus seems to be more correct, although I struggle to see how it could matter in practice. It does. See this thread: http://lists.gnu.org/archive/html/freetype-devel/2006-04/msg0.html But since the rest of the code really likes to use orus, it's best to keep using it in IP as well I suppose. Well, `orus' has been introduced just to cater rounding issues with the IP instruction. The attached patch fixes the bug, and does not change the case where x_scale and y_scale are equal, so it should be quite safe and not introduce any new bugs. Thanks a lot! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] FT_Outline_Embolden() is Blurry
In ftoutln.c there is a function called FT_Outline_Embolden(). This is used to create artificial emboldening, and is used when fontconfig requests emboldening for fonts that don't have a bold face available. Near the end of this function are these two lines, which actually perform the emboldening, in the x and y directions: outline-points[n].x = v_cur.x + strength + in.x; outline-points[n].y = v_cur.y + strength + in.y; Emboldening in the y direction can happen in fractions of a pixel, and this ends up being only in the up direction. The result of this is a blurry fringe on the tops of letters. While this may be technically correct, I'm wondering if *anyone* actually thinks this looks nice. In my patches, I disable the y direction completely, and the aesthetic improvements are dramatic, in my opinion. Is this something that can be done in Freetype instead? Or perhaps can the function be split into two? See this link for a comparison. The left side is with y-emboldening. The right is without y-emboldening. http://www.infinality.net/files/y-emboldening.png Thanks, Erik ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Outline_Embolden() is Blurry
Another thought I had just after sending the last email... Consider any font that has a bold face available: Arial, DejaVu, Lucida Grande, etc.. Their bold faces do not end up being any taller than the regular, non-bold faces. So, the fact that FT_Outline_Embolden() is making the glyphs taller seems to go against common practice. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] ttfautohint 0.6 has been released
Werner LEMBERG w...@gnu.org writes: Today in the morning, while still dozing, I had a great idea how to largely simplify hinting of composite glyphs, and which solves the Roboto issue at the same time. Heh, you have your best coding ideas while half-asleep too eh...? :} -miles -- Monday, n. In Christian countries, the day after the baseball game. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_Outline_Embolden() is Blurry
In ftoutln.c there is a function called FT_Outline_Embolden(). This is used to create artificial emboldening, and is used when fontconfig requests emboldening for fonts that don't have a bold face available. Near the end of this function are these two lines, which actually perform the emboldening, in the x and y directions: outline-points[n].x = v_cur.x + strength + in.x; outline-points[n].y = v_cur.y + strength + in.y; Emboldening in the y direction can happen in fractions of a pixel, and this ends up being only in the up direction. The result of this is a blurry fringe on the tops of letters. While this may be technically correct, I'm wondering if *anyone* actually thinks this looks nice. The code has been written in a quite generic way. IMHO, you need both horizontal and vertical emboldening for larger font sizes. I fully agree that it is suboptimal for small font sizes which are going to be used in combination with other fonts. In my patches, I disable the y direction completely, and the aesthetic improvements are dramatic, in my opinion. Is this something that can be done in Freetype instead? Or perhaps can the function be split into two? It can't be done currently. Please suggest a new API. And provide a patch (with a ChangeLog entry) :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
