Re: [ft-devel] a hidden gem: the autohint warper code
If the bottom line of the warped glyph is shifted away from a bluezone, then the whole glyph should be shifted back a whole 1 pixel back toward the bluezone after being warped. This won't work. If you shift one pixel back, all other optimized zones, would be at the wrong position. Warping, as it is currently implemented, only works if the code has the absolute freedom to positions stems at any places. To be more precise: The autohinter doesn't scale glyphs uniformly in the main hinting direction. Instead, it works similar to the TrueType bytecode hinter: The glyph's local and global main features are aligned to the pixel grid (as much as possible), then the remaining points are scaled relatively to the already aligned features. I think this is the optimum you can achieve. What is improvable, however, is the algorithm to decide which stems are `main features', and which features (e.g. serifs) must be handled specially. In particular, handling of diagonal stems might be improved. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
Werner LEMBERG w...@gnu.org writes: What is improvable, however, is the algorithm to decide which stems are `main features', and which features (e.g. serifs) must be handled specially. In particular, handling of diagonal stems might be improved. BTW, that's what sort of worried me about the recent hacks to the CJK autohinter: It seemed to work OK in the case posted, because the major skeleton strokes of the characters were grid-aligned, and the non-aligned (and thus less visible) strokes seemed well-chosen. But is that somehow guaranteed...? It seems like the result not aligning important strokes when minor strokes _were_ aligned would result in _less_ readable results than simply grid-aligning everything (as I guess happens now)... -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
On 2011-03-01, Werner LEMBERG w...@gnu.org wrote: If the bottom line of the warped glyph is shifted away from a bluezone, then the whole glyph should be shifted back a whole 1?pixel back toward the bluezone after being warped. This won't work. If you shift one pixel back, all other optimized zones, would be at the wrong position. Warping, as it is currently implemented, only works if the code has the absolute freedom to positions stems at any places. About the warper, Werner LEMBERG wrote: An example of (b) is the warper code in the autofit module (to be activated by defining AF_USE_WARPER in aftypes.h) which is highly dependent on the output resolution since it shifts and scales a glyph by tiny amounts until a best score is found; this score is based on how many `segments' (stems and similar features) are near to or located on grid lines. I assume when finding the best score, the shift and scale performed in the warper code are uniform over the whole glyph points. After tiny scaled/shifted, the stems are then grid fit to pixels. Then shifting back 1 pixel in the screen resolution will simply add a 64(?) font unit point *offset*. It won't effect the distance between a point and the nearest gid point. The grid fitting should fit toward the same side of grid except 1 pixel off. Or do it in another order, we can grid fitting normally first and then move the result down/up 1 pixel if needed, according the warper effect over bottom blue zone. Keep the shape, align the bottom. For example * Without warper, the bottom edge will autofit to line 1 (blue zone) * With warper, the bottom edge will autofit to line 0 * Autofit with warper normally * After autofit, shift the whole thing up 1 pixel to align the warper-autofited bottom edge to line 1. * If the un-warpered bottom edge don't fit to blue zone edge, do nothing. Are these steps make sense? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
On 2011-03-01, Miles Bader mi...@gnu.org wrote: Werner LEMBERG w...@gnu.org writes: What is improvable, however, is the algorithm to decide which stems are `main features', and which features (e.g. serifs) must be handled specially. In particular, handling of diagonal stems might be improved. BTW, that's what sort of worried me about the recent hacks to the CJK autohinter: It seemed to work OK in the case posted, because the major skeleton strokes of the characters were grid-aligned, and the non-aligned (and thus less visible) strokes seemed well-chosen. But is that somehow guaranteed...? It seems like the result not aligning important strokes when minor strokes _were_ aligned would result in _less_ readable results than simply grid-aligning everything (as I guess happens now)... It seems the hack assume stem are sperated by at least 1 pixel. The counter hinting concept of type1 font. So if 2 stems touched, the 2nd one was rendered non-aligned, thus grayscaled. The result is a bit fuzzy becaues of using grayscale instead of gridfitting. I guess it works better on odd stem sets (日) but not so well on even stem sets (且), the last stem will be fuzzied. Even if the 1st and last are gridfit, how to represent the middle 2 stems? A glob of gray or a zig-zag gray? or a verticle line? ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER. Oops! Forgot to commit and push. Now it's really in the git repository. Below you can find two links to images (from David Turner, who is testing and evaluating the warping stuff again). Please compare. http://img848.imageshack.us/img848/9311/wikigitwarpoff.png http://img852.imageshack.us/img852/3342/wikigitwarpon.png Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
On 03/01/11 22:24, Werner LEMBERG wrote: Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... I agree with David :). I guess warping may produce superior results if combined with correct lsb/rsb adjustment. But Firefox/Pango currently don't do that. So you get awful kerning between, say, ee in the example. behdad ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
[Umpf. Large emails are rejected by nongnu.org without giving any reasons. I would have expected that they get queued and I have to approve them as the list administrator of freetype-devel.] Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... I agree with David :). I guess warping may produce superior results if combined with correct lsb/rsb adjustment. But Firefox/Pango currently don't do that. So you get awful kerning between, say, ee in the example. Well, yes, the warping stuff needs more fine-tuning to avoid lsb/rsb issues. Attached are two images of ftdiff DejaVuSans.ttf at 12pt where you can see problems. http://img577.imageshack.us/img577/5118/dejavusans12nowarp.png http://img13.imageshack.us/img13/223/dejavusans12warp.png However, the two images which show the same at 11pt prove that considerable improvements *are* possible without affecting the spacing. http://img191.imageshack.us/img191/126/dejavusans11nowarp.png http://img848.imageshack.us/img848/9115/dejavusans11warp.png Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
Werner LEMBERG w...@gnu.org writes: Below you can find two links to images (from David Turner, who is testing and evaluating the warping stuff again). Please compare. http://img848.imageshack.us/img848/9311/wikigitwarpoff.png http://img852.imageshack.us/img852/3342/wikigitwarpon.png Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... Hmm Interestingly, it's not the shapes I notice so much, but that the _spacing_ in the hinting = on image looks vastly better. The spacing in the off image is downright awful. Not sure why this is so, but I'm guessing that the off image is using up extra columns of pixels for almost-unnoticeable fringes at the sides of characters, and the result is that there appears to be extra colums of whitespace inserted at those points... -Miles -- Scriptures, n. The sacred books of our holy religion, as distinguished from the false and profane writings on which all other faiths are based. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
From: Miles Bader mi...@gnu.org Subject: Re: [ft-devel] a hidden gem: the autohint warper code Date: Wed, 02 Mar 2011 16:01:28 +0900 Werner LEMBERG w...@gnu.org writes: Below you can find two links to images (from David Turner, who is testing and evaluating the warping stuff again). Please compare. http://img848.imageshack.us/img848/9311/wikigitwarpoff.png http://img852.imageshack.us/img852/3342/wikigitwarpon.png Interestingly, David thinks that the autohinter warping produces much worse results, while I consider exactly the opposite... Hmm Interestingly, it's not the shapes I notice so much, but that the _spacing_ in the hinting = on image looks vastly better. The spacing in the off image is downright awful. Not sure why this is so, but I'm guessing that the off image is using up extra columns of pixels for almost-unnoticeable fringes at the sides of characters, and the result is that there appears to be extra colums of whitespace inserted at those points... The too wide spacing (without the warper) is more or less an unwanted artifact of the autohinter. Maybe this can be improved by further tuning, but it's a difficult topic. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] a hidden gem: the autohint warper code
*I have noticed however that inter-character spacing can still *affected under LIGHT hinting, is that a bug? Good question. I don't know yet, but I'm studying the code right now and I probably can answer this soon. I've just played a bit with ftdiff: Activating the light hinter (by pressing `h') and comparing with the unhinted outlines, I don't see such an effect. Could you please give more details? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
