Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
I'm sorry for long long delay after your first post of blue zone patch. Just I've committed your patch to git head. Testing the latency for bluezone calculation by ftbench, I found that the bluezone patched version is not slower than the original. BTW, from a Korean expert in SC34/WG2, I heard that Korean font without CJK Ideographs are not so irregular (I think all Korean dejure standard of coded character sets include CJK Ideorgaphs, but...!), so I inserted "hani" (OpenType terminology to mean CJK Ideographs) to the name of the collection of sample CJK Ideographs to compute bluezones. Maybe I will work for sample characters for Hangul and some Indic scripts in future. Regards, mpsuzuki Just Fill Bugs wrote: > On 04/29/2011 01:22 AM, mpsuz...@hiroshima-u.ac.jp wrote: >> Looking at "想意理生當着" of afoff-afold-afnew_gray_wqyzh0945.png, >> I think that your patch removes the bumps of surplus vertical stems >> crossing the lowest horizontal stems of "當着" and lifts the lowest >> stems of "想意" to align to the lowest stems of other glyphs. >> >> I think the bumps of surplus vertical stems crossing the lower >> horizontal stem (lower-right and lower-left of "口" ) is very >> popular design of CJK Ideographs, and they are expected to be >> ignored in low resolution rasterization. So the lower bluezone >> implementation is good to include. BTW, I'm not sure if lower >> bluezone should have filled/unfilled distinction. If you have >> any example showing the requirement, please let me know. > > Well, the filled and unfilled distinction cannot be shown in wqy-zenhei > with the current state of the freetype2 stem detection. Some of the filled > stem terminal can be detected, some cannot. As can be seem from '林' > with my visual segment patch for ftgrid. > > Initially, I was trying to keep vertical stems and horizontal stems to > align to their own bluezone when the bluezone are different enough. > maybe at 20pt or 24pt, the 2 blue zones could differ more than 1 pixel. > > 2ndly, since glyphs end with vertical stem has different bottom from > those end with horizontal stem, By using both filled and unfilled blue > zones, we can have a bigger range to snap nearby edges. > > Since the matched blue zone is calculated from the absolute distance > before a blue zone to an edge, when the 2 blue zones are different, > we effectively can have a reasonable larger blue zone to match more > candidate stems. > > see 林 and 置. > > Now I think the 2nd reason overweight the 1st because blue zone is > most useful at smaller size. > >> About the other bluezones, it's difficult for me to recognize >> remarkable improvement. Talking about the height/width proportion >> of "想意", the non-autofitted results look like same size, but >> both (old/new) autofitted results look like different size >> (rather, "想" looks like as taller than "意"). > > That's obviously because we failed to detect a top segment/edge for > the 2 glyphs. Therefore we cannot 'lift' the top edges of the glyphs. At the > same time, the first detected horizontal edges are grid-fit to the lower > grid. The result is a pressed down perception on the top of the glyphs. > > Cannot do much with blue zone before we can detect all the ending of a > stem and also the extrema of a diagonal stem. It's not a problem of the > blue zone fitting. > > Well, maybe for the 想, if we can relax the threshold for finding matching > blue zone, the top of 目 will be matched to top blue zone and be lifted. > > Don't know how much false positive will get if we relax the threshold. > It will look bad if the horizontal stem of 木 in 想 also matches > the top blue zone. :( > >> Also the legibility >> of upper parts of "它" and "當" gets worse than old autofitter. > > That is the horizontal blue zone effect. Since you planned to turn > horizontal blue zone off, it should not be a problem. > > The other solution is to always expand the blue zones at smaller point > so we can be guaranteed to have greater or equal sized glyph. > > At lease we can use a 1/4 pixel as threshold for rounding blue zones > instead of 1/2 pixel we are currently used. > > The threshold for detecting matched blue zone can also be changed for > smaller font. But that can be done once the blue zone code is in place. > >> In summary, I think the lower bluezone would be worth to include >> in next release, but others are questionable, if my samples >> are appropriate to understand your proposals. Anyway, I think >> your approach is very good and I want to decide after complete >> reproduction of the demonstration. If GNU/Linux binary is acceptable, >> I will upload my ftstring binaries. >> > > It's ok with me. The bottom line zig-zag is an immediate problem for > CJK font at small size. Others are just bonus. > > > > > > This body part will be downloaded on demand. ___ Freetype-devel mailing list Free
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 05/08/2011 06:32 PM, suzuki toshiya wrote: > I'm sorry for long long delay after your first post of blue zone patch. > Just I've committed your patch to git head. > Thanks for your review and commit work. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Tweak CJK Blue zone parameters
Now that the CJK blue zone code are in the freetype repository, further tweak on the parameters can be performed. One thing that I can think of is that the threshold of best_dist0 used in the af_cjk_hints_compute_blue_edges(). best_dist0 is used to initialize the snap distant from edges to one of the blue zones. It's initially set to 1/40 of EM, and scaled to the rendering size. That means any edge that is closer to 1/40 of the EM (1024 or something) points toward a blue zone will snap to the blue zone. At smaller rendering size, we can have much less possible different edges in limited space. For example, at 16 pixel, we can only have 1/16 different edges, less than the 1/40. (more different edges when considering anti-alias rendering, but that's fuzzy.) Therefore, we can force a bigger snap distance so that we can have more uneven edges aligned. Especially when we deliberately merge some glyph features at the smaller font size. What's the suitable snap distance will vary over fonts. I wrote a patch to set the distance at 1/24 for 16px or smaller font size. Different numbers can be used to experiment with all kind of fonts. More dynamic adjustment can be archived by linking the best_dist0 value to the delta between filled/unfilled blue zones. diff --git a/src/autofit/afcjk.c b/src/autofit/afcjk.c index 101e668..513b0c0 100644 --- a/src/autofit/afcjk.c +++ b/src/autofit/afcjk.c @@ -1155,8 +1155,15 @@ FT_Posbest_dist0; /* initial threshold */ +FT_Fixed point_size = FT_MulFix( metrics->units_per_em / 64, scale ); + /* compute the initial threshold as a fraction of the EM size */ -best_dist0 = FT_MulFix( metrics->units_per_em / 40, scale ); +/* 16px or smaller font use bigger dist. */ +if ( point_size < 17 ) + best_dist0 = FT_MulFix( metrics->units_per_em / 24, scale ); +else + best_dist0 = FT_MulFix( metrics->units_per_em / 40, scale ); +FT_TRACE6(( "point_size: %li, best_dist0: %li\n", point_size, best_dist0 )); if ( best_dist0 > 64 / 2 ) /* Maximum 1/2 pixel */ best_dist0 = 64 / 2; ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Tweak CJK Blue zone parameters
Hi, If further tweak is needed for CJK bluezone, the code would be unmatured, I will disable it by default. In fact, the original demonstration was given by 11pt glyph of WenQuanYi-ZenHei, but your new tweak seems to change the dist value for the glyphs smaller than 17pt I think 17pt is unstable/temporal tuning value and not determined deducively. It makes me afraid that the code includes some ad-hoc parameters and they are not tested well. How long do you need to find stable values for the tunable parameters? If it is difficult to estimate, I will propose new API to manipulate the parameters by FT2 clients. Regards, mpsuzuki On Mon, 09 May 2011 00:23:58 +0800 Just Fill Bugs wrote: >Now that the CJK blue zone code are in the freetype repository, further >tweak on the parameters can be performed. > >One thing that I can think of is that the threshold of best_dist0 used >in the af_cjk_hints_compute_blue_edges(). best_dist0 is used to >initialize the snap distant from edges to one of the blue zones. > >It's initially set to 1/40 of EM, and scaled to the rendering size. That >means any edge that is closer to 1/40 of the EM (1024 or something) >points toward a blue zone will snap to the blue zone. > >At smaller rendering size, we can have much less possible different >edges in limited space. For example, at 16 pixel, we can only have >1/16 different edges, less than the 1/40. (more different edges when >considering anti-alias rendering, but that's fuzzy.) > >Therefore, we can force a bigger snap distance so that we can have more >uneven edges aligned. Especially when we deliberately merge some glyph >features at the smaller font size. > >What's the suitable snap distance will vary over fonts. I wrote a patch >to set the distance at 1/24 for 16px or smaller font size. Different >numbers can be used to experiment with all kind of fonts. > >More dynamic adjustment can be archived by linking the best_dist0 value >to the delta between filled/unfilled blue zones. > > ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Tweak CJK Blue zone parameters
On 05/09/2011 08:21 AM, mpsuz...@hiroshima-u.ac.jp wrote: If further tweak is needed for CJK bluezone, the code would be unmatured, I will disable it by default. In fact, the original demonstration was given by 11pt glyph of WenQuanYi-ZenHei, but your new tweak seems to change the dist value for the glyphs smaller than 17pt I think 17pt is unstable/temporal tuning value and not determined deducively. It makes me afraid that the code includes some ad-hoc parameters and they are not tested well. You don't have to include it. It's just some my brain storms I want to share with the list. The numbers are just some guess of mine. It is less aggressive than the numbers I tried at the beginning. When I test it, I meanly focused on 11pt, and tried to not over optimize it. One effect is that for 意 11pt, it raised the top horizontal edge to the top blue zone. Effectively pushed the dot over the blue zone. Limiting to 17pt is because I felt that, larger than 16pt, my eyes were more tolerant to the small even bottom line. Also around 15pt, the best_dist0 raised to 38 and was turned down to 36 by the safe guard in place. wqy-zenhei has an EM of 1024. How long do you need to find stable values for the tunable parameters? If it is difficult to estimate, I will propose new API to manipulate the parameters by FT2 clients. That's even better. Just don't know how many clients will use the API. Maybe through fontconfig? ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Tweak CJK Blue zone parameters
> How long do you need to find stable values for the tunable > parameters? This is never finished :-) Even for the latin autohinter, improvements or different approaches are always possible (cf. `latin2'). If it is difficult to estimate, I will propose new API > to manipulate the parameters by FT2 clients. Please no. It may be useful to have an easy way to manipulate the hinting process at compile time with a granularity down to a particular glyph in a particular font at a particular size (cf. the Infinality ClearType patches which will be added to FreeType quite soon), but exposing the autohinter internals to the public prevents any major change to the code, if ever necessary. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
