Re: [ft-devel] a hidden gem: the autohint warper code
Hi, Op 2 mrt 2011, om 04:24 heeft Werner LEMBERG het volgende geschreven: 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... Not sure if you were inviting comments from interested bystanders too, but I do think that the 'warp off' image has more consistent visual density. The weight from glyph to glyph seems to have more variation with warping on. It's hard to put this down to specific details of individual letters; it's more of an overall impression. Does that make sense at all? Kind regards, Emile van Bergen. ___ 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
Not sure if you were inviting comments from interested bystanders too, but I do think that the 'warp off' image has more consistent visual density. Thanks for chiming in. I'm interested in all opionions; the more, the better. The weight from glyph to glyph seems to have more variation with warping on. It's hard to put this down to specific details of individual letters; it's more of an overall impression. Interesting. Could you possibly cut out some relevant glyphs in the two images which demonstrate your observation? 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
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
Re: [ft-devel] a hidden gem: the autohint warper code
however are there any plans to make it warp in the y direction? No. By its very nature, such warping can't happen in the `main' hinting direction $(Q#|(B you would get uneven glyph heights if you do so. Also, does it operate in tandem with existing hinting techniques, or as an alternative? It's an improvement for the light rasterizer only. Were/are there future plans to expand upon this concept? Not that I'm aware of. What do you have in mind? The kind of rendering I am after is one where the shape of glyphs is retained as much as possible; so currently I use the light hinting mode to *only hint in the y direction and then rely on subpixel rendering to improve things in the x direction. I find this the best compromise; hinting in both directions just distorts things too much for my liking. Then warping is probably not what you want... In terms of whether to activate the option I would think it better to make it optional, for the reasons specified above - some people are likely using the light hinting mode specifically because it only affects things vertically, and this might scupper that approach. Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER. Of course, I am commenting without having really studied in detail the affects of enabling this option, though I can tell from your posted comparison that the warped text has significantly increased the overall length of the whole sentence. This varies. *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. 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 28 Feb 2011, at 23:10, Werner LEMBERG wrote: however are there any plans to make it warp in the y direction? No. By its very nature, such warping can't happen in the `main' hinting direction $(Q#| you would get uneven glyph heights if you do so. Could it not do something like pick a selection of key letters and work out how best to vertically warp these, using the scoring system, and then apply the same warp consistently across all glyphs? Similarly to how I assume regular hinting must work, at least in the sense that it must do the same thing to an F and an H with regards to snapping the middle horizontal bar. Ignore me if I'm talking horseshit though :) In terms of whether to activate the option I would think it better to make it optional, for the reasons specified above - some people are likely using the light hinting mode specifically because it only affects things vertically, and this might scupper that approach. Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER. Personally, I think as many options like this should be runtime-configurable as possible, so that there is maximum flexibility for applications in choosing how they want things to render rather than enforce a particular style of rendering/hinting across the board that requires a recompile to be changed. With that in mind, how about some more anti-aliasing options - it would be great to be able to emulate what Photoshop does with the *clear/sharp/strong/crisp selection (http://www.zeta.net/web-design/photoshop-anti-aliasing-for-web-design.html for examples) . as a games developer, the main complaint we have from the art team is why can't we render fonts like our photoshop mock-ups? Anyway, off at a tangent, sorry... Oliver. *that said, those four modes might be achievable via applying a filter to the existing greyscale/LCD coverage values anyway... ___ 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-02-28, Werner LEMBERG w...@gnu.org wrote: however are there any plans to make it warp in the y direction? No. By its very nature, such warping can't happen in the `main' hinting direction – you would get uneven glyph heights if you do so. Without blue zone treatment, glyphs always have uneven bottom line. I think the warp can be combined with bluezone management. 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. ___ 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
No. By its very nature, such warping can't happen in the `main' hinting direction $(Q#|(B you would get uneven glyph heights if you do so. Could it not do something like pick a selection of key letters and work out how best to vertically warp these, using the scoring system, and then apply the same warp consistently across all glyphs? Similarly to how I assume regular hinting must work, at least in the sense that it must do the same thing to an F and an H with regards to snapping the middle horizontal bar. Well, the code is already doing this! This is exactly how the autohinter works. Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER. Personally, I think as many options like this should be runtime-configurable as possible, so that there is maximum flexibility for applications in choosing how they want things to render rather than enforce a particular style of rendering/hinting across the board that requires a recompile to be changed. OK. Stay tuned. With that in mind, how about some more anti-aliasing options - it would be great to be able to emulate what Photoshop does with the *clear/sharp/strong/crisp selection (http://www.zeta.net/web-design/photoshop-anti-aliasing-for-web-design.html for examples) *that said, those four modes might be achievable via applying a *filter to the existing greyscale/LCD coverage values anyway... Well, within ftview, you can adjust the filter weights of the LCD filters, and you can adjust the gamma values also. Have you ever tried this? If you like to add more toys to ftview: patches are highly welcomed. 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 1 Mar 2011, at 09:19, Werner LEMBERG w...@gnu.orgmailto:w...@gnu.org wrote: No. By its very nature, such warping can't happen in the `main' hinting direction $(Q#|(B you would get uneven glyph heights if you do so. Could it not do something like pick a selection of key letters and work out how best to vertically warp these, using the scoring system, and then apply the same warp consistently across all glyphs? Similarly to how I assume regular hinting must work, at least in the sense that it must do the same thing to an F and an H with regards to snapping the middle horizontal bar. Well, the code is already doing this! This is exactly how the autohinter works. Yeah, what I meant is make the warper work vertically by warping a few sample glyphs to find the optimum warp and then apply to all glyphs. Currently it's a compile-time option, cf. AF_CONFIG_OPTION_USE_WARPER. Personally, I think as many options like this should be runtime-configurable as possible, so that there is maximum flexibility for applications in choosing how they want things to render rather than enforce a particular style of rendering/hinting across the board that requires a recompile to be changed. OK. Stay tuned. With that in mind, how about some more anti-aliasing options - it would be great to be able to emulate what Photoshop does with the *clear/sharp/strong/crisp selection (http://www.zeta.net/web-design/photoshop-anti-aliasing-for-web-design.htmlhttp://www.zeta.net/web-design/photoshop-anti-aliasing-for-web-design.html for examples) *that said, those four modes might be achievable via applying a *filter to the existing greyscale/LCD coverage values anyway... Well, within ftview, you can adjust the filter weights of the LCD filters, and you can adjust the gamma values also. Have you ever tried this? If you like to add more toys to ftview: patches are highly welcomed. Yeah I've tried all manner of gamma settings and LCD filters. Always end up back at the default LCD filter though, it's pretty solid. I do have some WIP for an algorithm that *intensifies typefaces in the manner of OS X which I'll happily supply as a patch if and when I'm 100% happy with it. It basically distorts the post-filtered LCD (or grayscale) values by boosting the effects of lower values in a smooth manner (tends things toward a curve) *aims to replicate the bolder/fuller effect of a) larger text and b) light text on dark backgrounds. 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
No. By its very nature, such warping can't happen in the `main' hinting direction – you would get uneven glyph heights if you do so. Without blue zone treatment, glyphs always have uneven bottom line. I think the warp can be combined with bluezone management. I don't think this is possible. 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. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
