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
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 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. <><><>___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Sorry for lated review. I've attached 2 PNGs: * afoff-afold-afnew_gray_wqyzh0626.png comparing 3 grayscale rasterization results for WenQuanYo-ZenHei 0.6.26 - autofit is off - old autofit (git 2011-04-18) - new autofit (git 2011-04-18 + your patch version 2.1) * afoff-afold-afnew_gray_wqyzh0945.png comparing 3 grayscale rasterization results for WenQuanYo-ZenHei 0.9.45 - autofit is off - old autofit (git 2011-04-18) - new autofit (git 2011-04-18 + your patch version 2.1) Please check if afoff-afold-afnew_gray_wqyzh0945.png reproduces the points you wanted to improve. For simplicity, I didn't apply the blurring patch for overcrowded strokes. If it is required, I will remake examples. 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. 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 "意"). Also the legibility of upper parts of "它" and "當" gets worse than old autofitter. 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. Regards, mpsuzuki On Sat, 23 Apr 2011 10:01:23 +0200 (CEST) Werner LEMBERG wrote: > >> There are indeed some problems with the patch. They happened when >> the bluezones were scaled at af_cjk_metrics_scale_dim() [...] >> >> I update the patch to the current git and address the problems. >> Please review the logic behind the idea. > >Thanks! I leave this to Toshiya-san for testing. > >> There could be other improvements when scaling the bluezone. Like >> under small size, round the bluezones to the ceiling >> unconditionally. That could make glyph bigger and clearer. But >> could make it 1 pixel extra bigger than the intended size. > >Well, what is the `intended size'? As we all know, it's impossible to >exactly find out the bbox of a glyph string without actually rendering >it, and it rarely happens that you get for, say, a 10pt font at 72dpi >a bbox height of 10 pixels. Additionally, bytecode instructions in >TrueType fonts modify the size also, sometimes rather drastically -- >in other words, I don't mind if a patch increases the size by one >pixel if legibility improves, provided this size fits (more or less) >with the non-CJK glyphs in the same font. > > >Werner > >___ >Freetype-devel mailing list >Freetype-devel@nongnu.org >https://lists.nongnu.org/mailman/listinfo/freetype-devel <><>___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
> There are indeed some problems with the patch. They happened when > the bluezones were scaled at af_cjk_metrics_scale_dim() [...] > > I update the patch to the current git and address the problems. > Please review the logic behind the idea. Thanks! I leave this to Toshiya-san for testing. > There could be other improvements when scaling the bluezone. Like > under small size, round the bluezones to the ceiling > unconditionally. That could make glyph bigger and clearer. But > could make it 1 pixel extra bigger than the intended size. Well, what is the `intended size'? As we all know, it's impossible to exactly find out the bbox of a glyph string without actually rendering it, and it rarely happens that you get for, say, a 10pt font at 72dpi a bbox height of 10 pixels. Additionally, bytecode instructions in TrueType fonts modify the size also, sometimes rather drastically -- in other words, I don't mind if a patch increases the size by one pixel if legibility improves, provided this size fits (more or less) with the non-CJK glyphs in the same font. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Oops, a bug fixed.
diff --git a/src/autofit/afcjk.c b/src/autofit/afcjk.c
index c15d343..2be157a 100644
--- a/src/autofit/afcjk.c
+++ b/src/autofit/afcjk.c
@@ -45,8 +45,456 @@
/*/
/*/
+ /* Basically the Latin version with AF_CJKMetrics to replace AF_LatinMetrics */
+ FT_LOCAL_DEF( void )
+ af_cjk_metrics_init_widths( AF_CJKMetricsmetrics,
+ FT_Face face,
+ FT_ULong charcode )
+ {
+/* scan the array of segments in each direction */
+AF_GlyphHintsRec hints[1];
+
+
+af_glyph_hints_init( hints, face->memory );
+
+metrics->axis[AF_DIMENSION_HORZ].width_count = 0;
+metrics->axis[AF_DIMENSION_VERT].width_count = 0;
+
+{
+ FT_Error error;
+ FT_UInt glyph_index;
+ int dim;
+ AF_CJKMetricsRec dummy[1];
+ AF_Scalerscaler = &dummy->root.scaler;
+
+
+ glyph_index = FT_Get_Char_Index( face, charcode );
+ if ( glyph_index == 0 )
+goto Exit;
+
+ error = FT_Load_Glyph( face, glyph_index, FT_LOAD_NO_SCALE );
+ if ( error || face->glyph->outline.n_points <= 0 )
+goto Exit;
+
+ FT_ZERO( dummy );
+
+ dummy->units_per_em = metrics->units_per_em;
+ scaler->x_scale = scaler->y_scale = 0x1L;
+ scaler->x_delta = scaler->y_delta = 0;
+ scaler->face= face;
+ scaler->render_mode = FT_RENDER_MODE_NORMAL;
+ scaler->flags = 0;
+
+ af_glyph_hints_rescale( hints, (AF_ScriptMetrics)dummy );
+
+ error = af_glyph_hints_reload( hints, &face->glyph->outline );
+ if ( error )
+goto Exit;
+
+ for ( dim = 0; dim < AF_DIMENSION_MAX; dim++ )
+ {
+AF_CJKAxisaxis= &metrics->axis[dim];
+AF_AxisHints axhints = &hints->axis[dim];
+AF_Segmentseg, limit, link;
+FT_UInt num_widths = 0;
+
+
+error = af_latin_hints_compute_segments( hints,
+ (AF_Dimension)dim );
+if ( error )
+ goto Exit;
+
+af_latin_hints_link_segments( hints,
+ (AF_Dimension)dim );
+
+seg = axhints->segments;
+limit = seg + axhints->num_segments;
+
+for ( ; seg < limit; seg++ )
+{
+ link = seg->link;
+
+ /* we only consider stem segments there! */
+ if ( link && link->link == seg && link > seg )
+ {
+FT_Pos dist;
+
+
+dist = seg->pos - link->pos;
+if ( dist < 0 )
+ dist = -dist;
+
+if ( num_widths < AF_CJK_MAX_WIDTHS )
+ axis->widths[ num_widths++ ].org = dist;
+ }
+}
+
+af_sort_widths( num_widths, axis->widths );
+axis->width_count = num_widths;
+ }
+
+ Exit:
+ for ( dim = 0; dim < AF_DIMENSION_MAX; dim++ )
+ {
+AF_CJKAxisaxis = &metrics->axis[dim];
+FT_Posstdw;
+
+
+stdw = ( axis->width_count > 0 )
+ ? axis->widths[0].org
+ : AF_LATIN_CONSTANT( metrics, 50 );
+
+/* let's try 20% of the smallest width */
+axis->edge_distance_threshold = stdw / 5;
+axis->standard_width = stdw;
+axis->extra_light = 0;
+ }
+}
+
+af_glyph_hints_done( hints );
+ }
+
+
+
+#define AF_CJK_MAX_TEST_CHARACTERS 32
+
+
+ /* Every blue zone has 2 types of fill and unfill,
+ * Which means fill the entire square or not.
+ * */
+ enum
+ {
+AF_CJK_BLUE_TYPE_FILL,
+AF_CJK_BLUE_TYPE_UNFILL,
+AF_CJK_BLUE_TYPE_MAX
+ };
+
+ /* Put some common and representative CJK characters here. */
+ static const FT_ULong af_cjk_blue_chars[AF_CJK_BLUE_MAX]
+ [AF_CJK_BLUE_TYPE_MAX]
+ [AF_CJK_MAX_TEST_CHARACTERS] =
+ {
+{
+ {
+ 0X4ED6, 0X4EEC, 0X4F60, 0X4F86, 0X5011, 0X5230, 0X548C, 0X5730,
+ 0X5BF9, 0X5C0D, 0X5C31, 0X5E2D, 0X6211, 0X65F6, 0X6642, 0X6703,
+ 0X6765, 0X70BA, 0X80FD, 0X8230, 0X8AAA, 0X8BF4, 0X8FD9, 0X9019,
+ 0X9F4A /* top fill */
+ },
+ {
+ 0X519B, 0X540C, 0X5DF2, 0X613F, 0X65E2, 0X661F, 0X662F, 0X666F,
+ 0X6C11, 0X7167, 0X73B0, 0X73FE, 0X7406, 0X7528, 0X7F6E, 0X8981,
+ 0X8ECD, 0X90A3, 0X914D, 0X91CC, 0X958B, 0X96F7, 0X9732, 0X9762,
+ 0X987E /* top unfill */
+ }
+},
+{
+ {
+ 0X4E2A, 0X4E3A, 0X4EBA, 0X4ED6, 0X4EE5, 0X4EEC, 0X4F60, 0X4F86,
+ 0X500B, 0X5011, 0X5230, 0X548C, 0X5927, 0X5BF9, 0X5C0D, 0X5C31,
+ 0X6211, 0X65F6, 0X6642, 0X6709, 0X6765, 0X70BA, 0X8981, 0X8AAA,
+ 0X8BF4 /* bottom fill */
+ },
+ {
+ 0X4E3B, 0X4E9B, 0X56E0, 0X5B83, 0X60F3, 0X610F, 0X7406, 0X751F,
+ 0X7576, 0X770B, 0X7740, 0X7F6E, 0X8005, 0X81EA, 0X8457,
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 04/21/2011 09:24 PM, Just Fill Bugs wrote:
I meant some steps were missing in the code. The bluezone is not
properly grid fit before the numbers being used to align segments.
There are indeed some problems with the patch. They happened when
the bluezones were scaled at af_cjk_metrics_scale_dim()
1. The shoot in cjk means undershoot, so the shoot should be the
smaller one.
2. The fit can be set at 1/2 a pixel in the patch. Maybe that is
useful for latin round edge. But for CJK, undershoot are straight
edge too. So 1/2 pixel is meaningless except creating blur.
3. The undershoot is compared to the un-fitted reference when
calculating a grid fit distance. But its fitted position was
calculated from fitted reference + fitted distance. This could
over-compensate the offset.
I update the patch to the current git and address the problems.
Please review the logic behind the idea.
There could be other improvements when scaling the bluezone. Like under
small size, round the bluezones to the ceiling unconditionally. That
could make glyph bigger and clearer. But could make it 1 pixel extra
bigger than the intended size.
diff --git a/src/autofit/afcjk.c b/src/autofit/afcjk.c
index c15d343..f12d0dd 100644
--- a/src/autofit/afcjk.c
+++ b/src/autofit/afcjk.c
@@ -45,8 +45,456 @@
/*/
/*/
+ /* Basically the Latin version with AF_CJKMetrics to replace AF_LatinMetrics */
+ FT_LOCAL_DEF( void )
+ af_cjk_metrics_init_widths( AF_CJKMetricsmetrics,
+ FT_Face face,
+ FT_ULong charcode )
+ {
+/* scan the array of segments in each direction */
+AF_GlyphHintsRec hints[1];
+
+
+af_glyph_hints_init( hints, face->memory );
+
+metrics->axis[AF_DIMENSION_HORZ].width_count = 0;
+metrics->axis[AF_DIMENSION_VERT].width_count = 0;
+
+{
+ FT_Error error;
+ FT_UInt glyph_index;
+ int dim;
+ AF_CJKMetricsRec dummy[1];
+ AF_Scalerscaler = &dummy->root.scaler;
+
+
+ glyph_index = FT_Get_Char_Index( face, charcode );
+ if ( glyph_index == 0 )
+goto Exit;
+
+ error = FT_Load_Glyph( face, glyph_index, FT_LOAD_NO_SCALE );
+ if ( error || face->glyph->outline.n_points <= 0 )
+goto Exit;
+
+ FT_ZERO( dummy );
+
+ dummy->units_per_em = metrics->units_per_em;
+ scaler->x_scale = scaler->y_scale = 0x1L;
+ scaler->x_delta = scaler->y_delta = 0;
+ scaler->face= face;
+ scaler->render_mode = FT_RENDER_MODE_NORMAL;
+ scaler->flags = 0;
+
+ af_glyph_hints_rescale( hints, (AF_ScriptMetrics)dummy );
+
+ error = af_glyph_hints_reload( hints, &face->glyph->outline );
+ if ( error )
+goto Exit;
+
+ for ( dim = 0; dim < AF_DIMENSION_MAX; dim++ )
+ {
+AF_CJKAxisaxis= &metrics->axis[dim];
+AF_AxisHints axhints = &hints->axis[dim];
+AF_Segmentseg, limit, link;
+FT_UInt num_widths = 0;
+
+
+error = af_latin_hints_compute_segments( hints,
+ (AF_Dimension)dim );
+if ( error )
+ goto Exit;
+
+af_latin_hints_link_segments( hints,
+ (AF_Dimension)dim );
+
+seg = axhints->segments;
+limit = seg + axhints->num_segments;
+
+for ( ; seg < limit; seg++ )
+{
+ link = seg->link;
+
+ /* we only consider stem segments there! */
+ if ( link && link->link == seg && link > seg )
+ {
+FT_Pos dist;
+
+
+dist = seg->pos - link->pos;
+if ( dist < 0 )
+ dist = -dist;
+
+if ( num_widths < AF_CJK_MAX_WIDTHS )
+ axis->widths[ num_widths++ ].org = dist;
+ }
+}
+
+af_sort_widths( num_widths, axis->widths );
+axis->width_count = num_widths;
+ }
+
+ Exit:
+ for ( dim = 0; dim < AF_DIMENSION_MAX; dim++ )
+ {
+AF_CJKAxisaxis = &metrics->axis[dim];
+FT_Posstdw;
+
+
+stdw = ( axis->width_count > 0 )
+ ? axis->widths[0].org
+ : AF_LATIN_CONSTANT( metrics, 50 );
+
+/* let's try 20% of the smallest width */
+axis->edge_distance_threshold = stdw / 5;
+axis->standard_width = stdw;
+axis->extra_light = 0;
+ }
+}
+
+af_glyph_hints_done( hints );
+ }
+
+
+
+#define AF_CJK_MAX_TEST_CHARACTERS 32
+
+
+ /* Every blue zone has 2 types of fill and unfill,
+ * Which means fill the entire square or not.
+ * */
+ enum
+ {
+AF_CJK_BLUE_TYPE_FILL,
+AF_CJK_BLUE_TYPE_UNFILL,
+AF_CJK_BLUE_TYPE_MAX
+ };
+
+ /* Put some
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Thank you for clarification, there is no problem in my procedure to take the screenshot? I will restart my evaluation from the source code on the day you posted the patch. Regards, mpsuzuki Just Fill Bugs wrote: > On 04/20/2011 09:27 PM, mpsuz...@hiroshima-u.ac.jp wrote: >> On Wed, 20 Apr 2011 14:53:08 +0200 (CEST) >> Werner LEMBERG wrote: >> It's kinda weird because the bluezones should be grid fit before being used to align stems. In the pictures, the top bluezone was obviously not grid fit. Maybe a step was missed. >>> Indeed, it looks odd. I was just going to write that I don't see a >>> real improvement... Toshiya-san, may I ask you to give a detailed >>> recipe how you've created those images? >> My pictures were taken as: >> ... > > I meant some steps were missing in the code. The bluezone is not > properly grid fit before the numbers being used to align segments. > > > > > ___ > Freetype-devel mailing list > Freetype-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 04/20/2011 09:27 PM, mpsuz...@hiroshima-u.ac.jp wrote: > On Wed, 20 Apr 2011 14:53:08 +0200 (CEST) > Werner LEMBERG wrote: > >>> It's kinda weird because the bluezones should be grid fit before >>> being used to align stems. In the pictures, the top bluezone was >>> obviously not grid fit. Maybe a step was missed. >> >> Indeed, it looks odd. I was just going to write that I don't see a >> real improvement... Toshiya-san, may I ask you to give a detailed >> recipe how you've created those images? > > My pictures were taken as: > ... I meant some steps were missing in the code. The bluezone is not properly grid fit before the numbers being used to align segments. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Just Fill Bugs wrote: > On 04/20/2011 08:34 PM, Just Fill Bugs wrote: >> On 04/20/2011 02:16 PM, mpsuz...@hiroshima-u.ac.jp wrote: >>> Maybe my impression about vertical bluezone is based on the >>> typography in Japanese market, so, I don't think this is >>> generic. Please let me know if there is such requirement in >>> Chinese or Korean typography. >> There is require to align side of glyph in vertical writing in Chinese. >> > > I meant to write "There is NO require to align side of glyph in vertical > writing Chinese." > > Sorry. Thanks! It seems to be consistent with other part of your post :-) Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 04/20/2011 08:34 PM, Just Fill Bugs wrote: > On 04/20/2011 02:16 PM, mpsuz...@hiroshima-u.ac.jp wrote: >> Maybe my impression about vertical bluezone is based on the >> typography in Japanese market, so, I don't think this is >> generic. Please let me know if there is such requirement in >> Chinese or Korean typography. > > There is require to align side of glyph in vertical writing in Chinese. > I meant to write "There is NO require to align side of glyph in vertical writing Chinese." Sorry. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On Wed, 20 Apr 2011 14:53:08 +0200 (CEST) Werner LEMBERG wrote: >>> Here is the anti-aliasing comparison. The patch makes the contrast >>> of some top horizontal strokes (因, 置,里, 面) weak. >> >> It's kinda weird because the bluezones should be grid fit before >> being used to align stems. In the pictures, the top bluezone was >> obviously not grid fit. Maybe a step was missed. > >Indeed, it looks odd. I was just going to write that I don't see a >real improvement... Toshiya-san, may I ask you to give a detailed >recipe how you've created those images? My pictures were taken as: 0) Build freetype2 and demos with default configuration (bytecode interpreter is built), with CFLAGS "-g3 -ggdb -O0 -fkeep-inline-functions -DFT_DEBUG_LEVEL_ERROR=7 -DFT_DEBUG_LEVEL_TRACE=7 -DFT_DEBUG_MEMORY=7" 1) Show the sample string by ftstring 2) Hit "h" key twice, and ensure the hinting is enabled. 3) Hit "f" key once, and ensure the auto-hinting is forced. 4) Take the screenshot. What was wrong? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Dear Sir, Thank you for quick reply. For fist, I comment about the requirement of the vertical blue zone. On Wed, 20 Apr 2011 20:34:52 +0800 Just Fill Bugs wrote: >On 04/20/2011 02:16 PM, mpsuz...@hiroshima-u.ac.jp wrote: >> Q1) The vertical bluezones are essential? >> >> In vertical CJK typography, there would be the requirement >> to align long center stems (of the glyphs like "十", "土", >> "王"), to pretend the centerlines of the glyphs are aligned. >> However, I'm questionable if there is a requirement to align >> non-center stems to be aligned. Maybe the alignment of the >> vertical stems of the radical-"enclosure" glyphs (like "回", >> "囚", "困") or radical-"gate" glyphs (like "門", "開", "閉" ) >> may improve the quality. But I'm questionable if there is >> the requirement to align the left vertical stems of radical >> "mound" glyphs (like "阿", "防", "阻"), or radical "mouse" >> glyphs (like "叫", "叩", "叱"). >> >> Maybe my impression about vertical bluezone is based on the >> typography in Japanese market, so, I don't think this is >> generic. Please let me know if there is such requirement in >> Chinese or Korean typography. > >There is require to align side of glyph in vertical writing in Chinese. > >For the vertical blue zone. Partly because I kinda misunderstood the >icfb tag describe by Adobe at > >http://partners.adobe.com/public/developer/opentype/index_tag4.html#ideoembox > >I guess it mostly talking about horizontal alignment using icfb, while I >mistook it's also used for vertical layout. Umm, I think, the requirement described in Adobe document is talking about the alignment of the rectangle to store the glyphs with reserved inter-glyph spaces (em-box, body size) and without reserved inter-glyph spaces (something like an integration of bounding box of the glyphs). It does not mean that there is a vertical alignment of the vertical stems. I will ask Adobe experts. >Another reason I consider to add vertical blue zone is that I don't know >how vertical layout looks like at small size on screen. Without blue >zone, the width of glyphs will vary quite frequently at small points. I >don't know how our eyes tolerant to that. Indeed. In my impression, the customers who request the vertical writing mode of digital text tend to prefer the paper-like appearance, so they are not interested in so much about the text with the small points at low resolution device. >Just better safe than sorry. Of course it can always be removed now and >add back by request. Although I'm going to disable the vertical alignment by default (to reduce the time of blue zone calculation), I appreciate that you included the code for vertical alignment. It would be really useful to draft the autofitter for the scripts using vertical alignment, like, Mongolian or Phaspa. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
>> Here is the anti-aliasing comparison. The patch makes the contrast >> of some top horizontal strokes (因, 置,里, 面) weak. > > It's kinda weird because the bluezones should be grid fit before > being used to align stems. In the pictures, the top bluezone was > obviously not grid fit. Maybe a step was missed. Indeed, it looks odd. I was just going to write that I don't see a real improvement... Toshiya-san, may I ask you to give a detailed recipe how you've created those images? Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 04/20/2011 07:31 PM, mpsuz...@hiroshima-u.ac.jp wrote: > > Here is the anti-aliasing comparison. The patch makes > the contrast of some top horizontal strokes (因, 置, > 里, 面) weak. > It's kinda weird because the bluezones should be grid fit before being used to align stems. In the pictures, the top bluezone was obviously not grid fit. Maybe a step was missed. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 04/20/2011 02:16 PM, mpsuz...@hiroshima-u.ac.jp wrote: > Q1) The vertical bluezones are essential? > > In vertical CJK typography, there would be the requirement > to align long center stems (of the glyphs like "十", "土", > "王"), to pretend the centerlines of the glyphs are aligned. > However, I'm questionable if there is a requirement to align > non-center stems to be aligned. Maybe the alignment of the > vertical stems of the radical-"enclosure" glyphs (like "回", > "囚", "困") or radical-"gate" glyphs (like "門", "開", "閉" ) > may improve the quality. But I'm questionable if there is > the requirement to align the left vertical stems of radical > "mound" glyphs (like "阿", "防", "阻"), or radical "mouse" > glyphs (like "叫", "叩", "叱"). > > Maybe my impression about vertical bluezone is based on the > typography in Japanese market, so, I don't think this is > generic. Please let me know if there is such requirement in > Chinese or Korean typography. There is require to align side of glyph in vertical writing in Chinese. For the vertical blue zone. Partly because I kinda misunderstood the icfb tag describe by Adobe at http://partners.adobe.com/public/developer/opentype/index_tag4.html#ideoembox I guess it mostly talking about horizontal alignment using icfb, while I mistook it's also used for vertical layout. Another reason I consider to add vertical blue zone is that I don't know how vertical layout looks like at small size on screen. Without blue zone, the width of glyphs will vary quite frequently at small points. I don't know how our eyes tolerant to that. Just better safe than sorry. Of course it can always be removed now and add back by request. > > Q2) What kind of glyphs are good to calculate the fill bluezone? > > It seems that the characters to calculate the top-fill bluezone > is collected from the characters which have some peak/apex in > upper boundary but have no horizontal strokes. Is it possible to > reduce the testing characters by using the characters with the > the radicals with peak, like, "京" (radical lid), "令" (radical > man), "安" (radical roof), "床" (radical dotted-cliff), "草" > (radical grass)? > In my personal opinion, using "dot beyond horizontal stroke" is > good benchmark to reserve the room of the dot in low resolution. > Top fill really just verticle stems and dot like strokes which are more extruded than horizontal stems. I agree. For complex enough character, dot like strokes are more representative. > > However, some strokes have inconstant line width issues; > the top horizontal stroke of "面" is typical example. > "看" in IPA Gothic shows similar issue. Maybe this can be alleviated by take into account the accumulated small 'drift' of alignment of previous stems as aflatin2.c did. And turn on grey scale rendering should help too. > > I think your patch is very good but the list of testing > characters requires more discussion. So I will try to add > new API for the client to modify the list. > Thanks for your work! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Hi, Here is the anti-aliasing comparison. The patch makes the contrast of some top horizontal strokes (因, 置, 里, 面) weak. # I'm sorry, my previous comparison lost 3 characters # (?) because I've edited UTF-8 sh script by # iso-2022 locale. Regards, mpsuzuki On Wed, 20 Apr 2011 18:38:18 +0900 suzuki toshiya wrote: >The reason why I switched off the anti-aliasing was that the original >comparison posted by JustFillBug was the comparison of B/W rendering. >Anyway, I have to agree with that it is not practical condition. I will >make the picture comparing them under anti-aliasing cases. > >Regards, >mpsuzuki > >Werner LEMBERG wrote: >>> Also I attached the comparison of 3 typefaces. >> >> Just a general question: Are you using B/W rendering in your images >> for demonstration purposes only? At such small sizes, the autohinter >> produces bad results if not using AA rendering. Even with TT >> instructions, CJK fonts normally contain bitmap strikes for these >> sizes to avoid rendering issues... >> >> >> Werner > > >___ >Freetype-devel mailing list >Freetype-devel@nongnu.org >http://lists.nongnu.org/mailman/listinfo/freetype-devel <>___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
The reason why I switched off the anti-aliasing was that the original comparison posted by JustFillBug was the comparison of B/W rendering. Anyway, I have to agree with that it is not practical condition. I will make the picture comparing them under anti-aliasing cases. Regards, mpsuzuki Werner LEMBERG wrote: >> Also I attached the comparison of 3 typefaces. > > Just a general question: Are you using B/W rendering in your images > for demonstration purposes only? At such small sizes, the autohinter > produces bad results if not using AA rendering. Even with TT > instructions, CJK fonts normally contain bitmap strikes for these > sizes to avoid rendering issues... > > > Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
> Also I attached the comparison of 3 typefaces. Just a general question: Are you using B/W rendering in your images for demonstration purposes only? At such small sizes, the autohinter produces bad results if not using AA rendering. Even with TT instructions, CJK fonts normally contain bitmap strikes for these sizes to avoid rendering issues... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Dear Sir, Now I'm reviewing your patch to improve bluezones for CJK Ideographs, and have 2 questions. Q1) The vertical bluezones are essential? In vertical CJK typography, there would be the requirement to align long center stems (of the glyphs like "十", "土", "王"), to pretend the centerlines of the glyphs are aligned. However, I'm questionable if there is a requirement to align non-center stems to be aligned. Maybe the alignment of the vertical stems of the radical-"enclosure" glyphs (like "回", "囚", "困") or radical-"gate" glyphs (like "門", "開", "閉" ) may improve the quality. But I'm questionable if there is the requirement to align the left vertical stems of radical "mound" glyphs (like "阿", "防", "阻"), or radical "mouse" glyphs (like "叫", "叩", "叱"). Maybe my impression about vertical bluezone is based on the typography in Japanese market, so, I don't think this is generic. Please let me know if there is such requirement in Chinese or Korean typography. Q2) What kind of glyphs are good to calculate the fill bluezone? It seems that the characters to calculate the top-fill bluezone is collected from the characters which have some peak/apex in upper boundary but have no horizontal strokes. Is it possible to reduce the testing characters by using the characters with the the radicals with peak, like, "京" (radical lid), "令" (radical man), "安" (radical roof), "床" (radical dotted-cliff), "草" (radical grass)? In my personal opinion, using "dot beyond horizontal stroke" is good benchmark to reserve the room of the dot in low resolution. -- Also I attached the comparison of 3 typefaces. >From top to bottom: 1) WQY ZenHei, version 0.6.26, 2008-Jun-25 2) IPA Gothic (Japanese), version 1.0, 2003 3) AR PL ZenKai Uni (Taiwanese), version 0.1, 2005-Aug-11 For each typeface, the upper is git 2011-Apr-13 without your patch and the lower is git 2011-Apr-13 with your patch. Some glyphs are clearly improved (進過道還), even in Kaishu case. This is very good. However, some strokes have inconstant line width issues; the top horizontal stroke of "面" is typical example. "看" in IPA Gothic shows similar issue. I think your patch is very good but the list of testing characters requires more discussion. So I will try to add new API for the client to modify the list. Regards, mpsuzuki <>___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
> If the blue zone hinting for CJK is accepted as useful, then > adjusting the parameters is something that have to be done by people > with a lot of fonts. I don't have much fonts myself. Exactly. I don't see any obstacles in integrating your patch (except that I don't have time for it yet), but testing is crucial, and we need someone who is willing to do that... Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 2011-01-14, JustFillBug wrote: > Two things. > > 1. There are always some chars that have higher bottom lines either by >design or by mistake. Chars like 日, 士 might be designed to have a >higher bottom in certain fonts. Which cannot be corrected by auto >hinting. > > 2. Parameters used by the auto hinter are choosen by experience. A set >of parameters perfect for one font at certain scaling size might not >be very good for another font or at another scaling size. > >The patch inherited blue zone threshold parameters of latin script. >Which is 1/40 of EM for the zone width, and max out at 1/2 pixel. > >Since ideographs are more sensitive to bottom line alignment at >smaller font size than latin glyphs, we can relax those parameters >some more. > And the effect of Blue zone management is two fold. 1. to align similar bounding edges to a unified value. to straight up bottom line. 2. to unify sharp bottom/top and flat bottom/top at small font size. This's important in practicle text run when flat and sharp bottoms interleave randomly. The test sample used all the flat bottom chars to show blue zone effect, because non-stem edges are not well detected when there are a small curve on the edges. As a result, effect no. 2 of blue zone management cannot be shown in the test sample. The algorithm used in freetype's auto hinter is documented at http://freetype.sourceforge.net/autohinting/hinter.html ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 2011-01-13, Miles Bader wrote: > > The "with blue" and "no blue" renderings are surely different, in terms > of vertical alignment at the bottom, but it's not clear to me which is > actually _best_... the "no blue" rendering looks more even though. > > What are the rules about vertical alignment with CJK fonts? [Especially > at low resolutions, where many characters end up having wide flat > bottoms even if they're not flat at high resolutions.] > > In particular, these two characters: "置者" look a bit unbalanced in the > "with blue" rendering, but look nicer to me in the "no blue" rendering > because at least their flat bottoms are aligned. > Two things. 1. There are always some chars that have higher bottom lines either by design or by mistake. Chars like 日, 士 might be designed to have a higher bottom in certain fonts. Which cannot be corrected by auto hinting. 2. Parameters used by the auto hinter are choosen by experience. A set of parameters perfect for one font at certain scaling size might not be very good for another font or at another scaling size. The patch inherited blue zone threshold parameters of latin script. Which is 1/40 of EM for the zone width, and max out at 1/2 pixel. Since ideographs are more sensitive to bottom line alignment at smaller font size than latin glyphs, we can relax those parameters some more. If I choose 1/32 of EM, max out at 3/4 pixel, I will have wider alignment range up to 16 ~ 18 font size for this particular font. If the blue zone hinting for CJK is accepted as useful, then adjusting the parameters is something that have to be done by people with a lot of fonts. I don't have much fonts myself. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
JustFillBug writes: > At 11pt, the bottom of the last few chars will clearly show the > effect. I attached an pic with anti-alias off. anti-aliased version > also shows the effect. The "with blue" and "no blue" renderings are surely different, in terms of vertical alignment at the bottom, but it's not clear to me which is actually _best_... the "no blue" rendering looks more even though. What are the rules about vertical alignment with CJK fonts? [Especially at low resolutions, where many characters end up having wide flat bottoms even if they're not flat at high resolutions.] In particular, these two characters: "置者" look a bit unbalanced in the "with blue" rendering, but look nicer to me in the "no blue" rendering because at least their flat bottoms are aligned. Thanks, -miles -- Barometer, n. An ingenious instrument which indicates what kind of weather we are having. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 2011-01-10, mpsuz...@hiroshima-u.ac.jp wrote: > Excuse me, could you give me some infos to check > the effect of you patch? > > * a font showing the effect of the improvement > * the configuration of FreeType2 > * the viewer and its configuration to show the glyphs > (ftview, without embedded bitmap, with hinting, with anti-alias?) > * string/text to be shown by the viewer > (the list of characters to calculate blue zones is it?) > * I used wqy-zenhei. Now I see it, this's a pretty old version: 0.8.34. Later versions have better bottom line alignment. http://sourceforge.net/projects/wqy/files/wqy-zenhei/ * Plain git freetype autogen.sh. I defined AF_DEBUG=1 at ./configure. Also I assigned _af_debug=1 at src/autofit/afmodule.c to read debug output. * I used freetype's ftstring. * The string is the text used to calculate bottom blue zone. The 2nd one, with flat bottoms. At 11pt, the bottom of the last few chars will clearly show the effect. I attached an pic with anti-alias off. anti-aliased version also shows the effect. #!/bin/sh # vim :set fileencoding=utf-8 ./ftstring -m "主些因它想意理生當看着置者自著裡过还进進過道還里面" 11 ~/.fonts/wqy-zenhei.ttc ; exit ./ftstring -m "Y" 11 ~/.fonts/wqy-zenhei.ttc ; exit <>___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Excuse me, could you give me some infos to check the effect of you patch? * a font showing the effect of the improvement * the configuration of FreeType2 * the viewer and its configuration to show the glyphs (ftview, without embedded bitmap, with hinting, with anti-alias?) * string/text to be shown by the viewer (the list of characters to calculate blue zones is it?) Regards, mpsuzuki On Sat, 8 Jan 2011 11:13:30 + (UTC) JustFillBug wrote: >On 2011-01-08, Werner LEMBERG wrote: >> >> It shouldn't be hard to fix this. However, I have not enough time >> currently, but I'll soon start (within two weeks I guess) to work >> intensively on the autohinter. >> > >Wow! This is a news too the Free Source world! > > > >___ >Freetype-devel mailing list >Freetype-devel@nongnu.org >http://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 2011-01-08, Werner LEMBERG wrote: > > It shouldn't be hard to fix this. However, I have not enough time > currently, but I'll soon start (within two weeks I guess) to work > intensively on the autohinter. > Wow! This is a news too the Free Source world! ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 2011-01-08, mpsuz...@hiroshima-u.ac.jp wrote: > I will take a look and try to make a list of > frequently used CJK Unified Ideographs used in > Japanese market. That will be great. > > Your message lacks the character encoding - > I guess it is coded by GBK. If my guessing > is correct... I think the list includes both > of Traditional & Simplified Hanzi. Many are > paired, but some are not paird. For example, > simplified form of "military" (U+519B) is > included, but traditional form (軍, U+8ECD) > is not included. GBK encoding is correct. I first made a simplified Chinese list, then convert it to traditional Chinese (iconv -f gb2312 -t big5). After that, duplicate chars are removed, also the unsuitable chars. So other than the simpl/trad pairs, other chars are both traditional and simplified. :) > > If a legacy Big5 font without any simplified > Hanzi is given, this patch works well? Or, > should we maintain another list for Big5? It seems the CJK fitter first switches to Unicode cmap before doing it work, in af_cjk_metrics_init(). Because it need to make sure the char ranges it works on are CJK ideographs. Therefore, a font without an unicode cmap don't likely get CJK autofitter. That's just my guess. > > Also, U+8ECD is included in GB 12345-90, > but not in GB 2312-80. If a legacy GB 2312 > font is given, this patch works well? > In af_cjk_metrics_init_blues(), if a char is not in a font, it's skipped. The same is true for latin fitter. No problem with unknown char. The worst case is that none of the listed char are in the font. Then no blue zone can be calculated. That way, the blue zone fitting will be ignored. Another bad scenario is that a bad blue zone is used, in that case, hopefully, nothing bad happens. Blue zone works by align points that are close enough to it and ignore far away points. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
> The real problem is that the Latin segment detector cannot find the > terminal segment if there is a slight curvature there. That's, if > there is slightly off the spline control point between the 2 anchor > point of a terminal segment, the segment cannot be detected. As > shown in the attached example. > > If someone can improve this situation, it will be greatly appreciated. It shouldn't be hard to fix this. However, I have not enough time currently, but I'll soon start (within two weeks I guess) to work intensively on the autohinter. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
On 2011-01-08, JustFillBug wrote: > > Issues: >=== > The way the edges are detected in CJK autofitter is different from Latin > autofitter. As can be seem using fontforge autofit function. > > In Latin code, there are 'single' edges which do not pair with any other > edges. While in CJK fitter, the 'single' edges are lost. So the bottom > edge on stroke like Y will not be detected by the CJK fitter. > I was wrong here. The CJK fitter uses the same routine as Latin fitter to detect segments and edges. The real problem is that the Latin segment detector cannot find the terminal segment if there is a slight curvature there. That's, if there is slightly off the spline control point between the 2 anchor point of a terminal segment, the segment cannot be detected. As shown in the attached example. If someone can improve this situation, it will be greatly appreciated. <>___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Oops, I'm sorry, I've overlooked that U+8ECD is not paird but included. But my questions are almost same... On Sat, 8 Jan 2011 17:17:12 +0900 mpsuz...@hiroshima-u.ac.jp wrote: >I guess it is coded by GBK. If my guessing >is correct... I think the list includes both >of Traditional & Simplified Hanzi. Many are >paired, but some are not paird. For example, >simplified form of "military" (U+519B) is >included, but traditional form (軍, U+8ECD) >is not included. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [Patch] CJK autofit/autohint blue zones
Hi, Thank you very much for posting interesting idea and the implementation for proof of concept!! I really appreciate for your effort. I will take a look and try to make a list of frequently used CJK Unified Ideographs used in Japanese market. On Sat, 8 Jan 2011 05:13:29 + (UTC) JustFillBug wrote: >Data: >= >The character used to calculate blue zones are some high freqeuncy >Chinese characters which reflect the needed feature. > >Maybe some frequently used Japanese and Korean Hanzi should be added >too. > >The characters picked are: Your message lacks the character encoding - I guess it is coded by GBK. If my guessing is correct... I think the list includes both of Traditional & Simplified Hanzi. Many are paired, but some are not paird. For example, simplified form of "military" (U+519B) is included, but traditional form (軍, U+8ECD) is not included. Yet I've not checked the cross section of them with popular legacy charsets like GB 2312 and Big5, but please let me ask a question. If a legacy Big5 font without any simplified Hanzi is given, this patch works well? Or, should we maintain another list for Big5? Also, U+8ECD is included in GB 12345-90, but not in GB 2312-80. If a legacy GB 2312 font is given, this patch works well? Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
