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 attachment: comparison-mps_20110420.png___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Any tool that visually present segments of autofit module?
A few months ago you've written: Are there any tool which visually present segments of autofit module? Something like stems shown in the glyph view of fontforge. No, but I'll probably add this to ftgrid since it would be helpful for my work on the ttfautohint stuff. But it isn't an urgent issue, and in case you have time to implement it I would be very grateful :-) It seems that ftgrid can dump autofit segment data to the terminal. But it's awkward to use with no label on the axis. Yep, another thing which should be added. Besides, that function was broken. I attached a patch to re-enable the function. Thanks. I've fixed that differently in ftgrid so that you get dumps only if the autofitter is active. The ftgrid binary need to be recompiled against a freetype lib with AF_DEBUG defined. I see no benefit of this forced recompilation other than a slightly less symbol pollution. Again, I've applied a different solution by replacing the local AF_DEBUG with a global FT_DEBUG_AUTOFIT macro in `ftoption.h' which is enabled by default if you say `make devel; make'. 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] FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH by default?
Every user of FreeType that I know has once in their lifetime hit the bug that with many common CJK fonts, non-CJK characters take doublewidth where they should take a single one. The fix always has been to pass FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to FreeType, as the fonts have the bit set wrongly. A monospace CJK font is never monospace. It has single-width glyphs, and double-width, hence setting global-advance is wrong in the font. But since this is such a common issue, I wonder if FreeType should simply ignore global advance by default. Cairo and fontconfig always pass that flag to FreeType. I've seen this bug hit Qt before. And most recently I watched it hit Skia. I've already pondered about this problem, but I've found no solution which guarantees backwards compatibility. Your idea of completely ignoring this flag didn't come to my mind :-) Since your suggestion sounds sensible, could you provide a patch? 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
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 Autohinter should not clump stems together when there are too many of them
Hi,
Sorry for lated review of your patch. I made slight revise
to your patch, it's almost ready to commit.
One of my anxiety was that the priority to the black/white
evenness can reduce the contrast of the complex glyph.
Please find attached picture comparing the results by
HeiseiMaruGo-W4 at 16pt @ 72dpi. In my personal impression,
the legibility of the strokes in enclosed area (like 日
or 目) is not important, but the legibility of the longest
stroke should be respected. Please let me know how your
opinion.
Regards,
mpsuzuki
diff --git a/builds/unix/install-sh b/builds/unix/install-sh
old mode 100644
new mode 100755
diff --git a/src/autofit/afcjk.c b/src/autofit/afcjk.c
index af4597c..a291fc3 100644
--- a/src/autofit/afcjk.c
+++ b/src/autofit/afcjk.c
@@ -1025,6 +1025,8 @@
AF_Edge anchor = 0;
FT_Posdelta= 0;
FT_Intskipped = 0;
+FT_Bool has_last_stem = 0;
+FT_Poslast_stem_pos = 0;
/* now we align all stem edges. */
@@ -1044,12 +1046,34 @@
continue;
}
+ /* Some CJK characters have so many stems that
+ * the hinter is likely to merge two adjacent ones.
+ * To solve this problem, if either edge of a stem
+ * is too close to the previous one, we avoid
+ * aligning the two edges, but rather interpolate
+ * their locations at the end of this function in
+ * order to preserve the space between the stems.
+ */
+ if ( has_last_stem
+ ( edge-pos last_stem_pos + 64 ||
+ edge2-pos last_stem_pos + 64 ) )
+ {
+skipped++;
+continue;
+ }
+
/* now align the stem */
if ( edge2 edge )
{
af_cjk_align_linked_edge( hints, dim, edge2, edge );
edge-flags |= AF_EDGE_DONE;
+/* We rarely reaches here it seems;
+ * usually the two edges belonging
+ * to one stem are marked as DONE together
+ */
+has_last_stem = 1;
+last_stem_pos = edge-pos;
continue;
}
@@ -1142,6 +1166,8 @@
anchor = edge;
edge-flags |= AF_EDGE_DONE;
edge2-flags |= AF_EDGE_DONE;
+ has_last_stem = 1;
+ last_stem_pos = edge2-pos;
}
/* make sure that lowercase m's maintain their symmetry */
On Sun, 20 Feb 2011 16:11:22 +0900
mpsuz...@hiroshima-u.ac.jp wrote:
Hi,
On Sun, 20 Feb 2011 07:43:54 +0100 (CET)
Werner LEMBERG w...@gnu.org wrote:
Some Chinese characters, such as 量 and 置, have a large number of
horizontal stems. At ordinary sizes, the autohinter will often
clump adjacent stems together; although the result remains readable,
the unevenness of black and white looks rather ugly.
afcjk.patch is my patch that attempts to solve this problem. All
stems that are pixel-aligned have at least one pixel of space (or
other stems) in between. Other stems are not aligned, but only have
their position interpolated, so they have the un-hinted look which
is IMHO better.
Thanks for your patch; it looks reasonable. Toshiya-san, could you
please comment?
Indeed, the rasterization result of patched version is
better than original version. I want to check if it
works well for other fonts, especially the typeface
using non-flat-width strokes, like KaiShu. Please give
me 1 or 2 weeks...
Regards,
mpsuzuki
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
attachment: HeiseiMaruGo.png___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] CJK Autohinter should not clump stems together when there are too many of them
One of my anxiety was that the priority to the black/white evenness can reduce the contrast of the complex glyph. Please find attached picture comparing the results by HeiseiMaruGo-W4 at 16pt @ 72dpi. In my personal impression, the legibility of the strokes in enclosed area (like 日 or 目) is not important, but the legibility of the longest stroke should be respected. Please let me know how your opinion. Thanks for reviewing. Do you have an idea how to increase the legibility of the longest strokes? Contrary to the proposed patch I think that this what you suggest is quite hard a job to achieve since you not only have to do feature analysis, e.g., mark horizontal stems which are surrounded by vertical stems like this |-| as `unimportant', but also distort the glyph accordingly so that `important' stems are aligned to the grid... Please commit to the git repository if you think that your reviewed patch is OK now. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] CJK Autohinter should not clump stems together when there are too many of them
On Wed, 20 Apr 2011 12:35:29 +0200 (CEST) Werner LEMBERG w...@gnu.org wrote: One of my anxiety was that the priority to the black/white evenness can reduce the contrast of the complex glyph. Please find attached picture comparing the results by HeiseiMaruGo-W4 at 16pt @ 72dpi. In my personal impression, the legibility of the strokes in enclosed area (like 日 or 目) is not important, but the legibility of the longest stroke should be respected. Please let me know how your opinion. Thanks for reviewing. Do you have an idea how to increase the legibility of the longest strokes? Contrary to the proposed patch I think that this what you suggest is quite hard a job to achieve since you not only have to do feature analysis, e.g., mark horizontal stems which are surrounded by vertical stems like this |-| as `unimportant', but also distort the glyph accordingly so that `important' stems are aligned to the grid... I think what I requested (the longest stem should not be blurred) is difficult to co-exist with the proposed patch. So, if we find some comments that the rasterized result by 2.2.5 is too blurred and 2.2.4 is better, I will propose to revert the patch and discuss the appropriate condition to enable the feature. Fortunately, the proposed patch is not drastic. Please commit to the git repository if you think that your reviewed patch is OK now. OK, I will apply it within 24 hours. 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
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 mpsuz...@hiroshima-u.ac.jp 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 attachment: comparison-mps_20110420b.png___ 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
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 Autohinter should not clump stems together when there are too many of them
On 04/20/2011 06:35 PM, Werner LEMBERG wrote: Thanks for reviewing. Do you have an idea how to increase the legibility of the longest strokes? Contrary to the proposed patch I think that this what you suggest is quite hard a job to achieve since you not only have to do feature analysis, e.g., mark horizontal stems which are surrounded by vertical stems like this |-| as `unimportant', but also distort the glyph accordingly so that `important' stems are aligned to the grid... There could be an extra step for grouping stems. Stems belong to the same contour or surrounded by a outer contour are grouped together. Counter hinting could be performed on intra and inter groups. ___ 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
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] FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH by default?
On 04/20/11 03:11, Werner LEMBERG wrote:
Every user of FreeType that I know has once in their lifetime hit
the bug that with many common CJK fonts, non-CJK characters take
doublewidth where they should take a single one. The fix always has
been to pass FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH to FreeType, as the
fonts have the bit set wrongly. A monospace CJK font is never
monospace. It has single-width glyphs, and double-width, hence
setting global-advance is wrong in the font.
But since this is such a common issue, I wonder if FreeType should
simply ignore global advance by default. Cairo and fontconfig
always pass that flag to FreeType. I've seen this bug hit Qt
before. And most recently I watched it hit Skia.
I've already pondered about this problem, but I've found no solution
which guarantees backwards compatibility. Your idea of completely
ignoring this flag didn't come to my mind :-)
Since your suggestion sounds sensible, could you provide a patch?
Attached. You also need to update the ft2demos that use it to remove the
option (ftdiff, etc).
behdad
Werner
commit 544aeed84bd287a6897e341025c8a15dcbc29361
Author: Behdad Esfahbod beh...@behdad.org
Date: Wed Apr 20 14:52:12 2011 -0400
Always ignore global advance
This makes FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH redundant, deprecated,
and ignored. The new behavior is what every major user of FreeType
has been requesting. Global advance is broken in many CJK fonts.
Just ignoring it by default makes most sense.
diff --git a/builds/unix/install-sh b/builds/unix/install-sh
old mode 100644
new mode 100755
index a5897de..6781b98
--- a/builds/unix/install-sh
+++ b/builds/unix/install-sh
@@ -1,7 +1,7 @@
#!/bin/sh
# install - install a program, script, or datafile
-scriptversion=2006-12-25.00
+scriptversion=2009-04-28.21; # UTC
# This originates from X11R5 (mit/util/scripts/install.sh), which was
# later released in X11R6 (xc/config/util/install.sh) with the
@@ -515,5 +515,6 @@ done
# eval: (add-hook 'write-file-hooks 'time-stamp)
# time-stamp-start: scriptversion=
# time-stamp-format: %:y-%02m-%02d.%02H
-# time-stamp-end: $
+# time-stamp-time-zone: UTC
+# time-stamp-end: ; # UTC
# End:
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index b9e34e2..3956676 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -2444,13 +2444,7 @@ FT_BEGIN_HEADER
* in fonts. By default, FreeType tries to handle broken fonts also.
*
* FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH ::
- * Indicates that the font driver should ignore the global advance
- * width defined in the font. By default, that value is used as the
- * advance width for all glyphs when the face has
- * @FT_FACE_FLAG_FIXED_WIDTH set.
- *
- * This flag exists for historical reasons (to support buggy CJK
- * fonts).
+ * Ignored. Deprecated.
*
* FT_LOAD_NO_RECURSE ::
* This flag is only used internally. It merely indicates that the
diff --git a/src/truetype/ttdriver.c b/src/truetype/ttdriver.c
index d723b57..fd30661 100644
--- a/src/truetype/ttdriver.c
+++ b/src/truetype/ttdriver.c
@@ -135,8 +135,6 @@
{
FT_UInt nn;
TT_Face face = (TT_Face) ttface;
-FT_Bool check = FT_BOOL(
- !( flags FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH ) );
/* XXX: TODO: check for sbits */
@@ -149,7 +147,7 @@
FT_UShort ah;
-TT_Get_VMetrics( face, start + nn, check, tsb, ah );
+TT_Get_VMetrics( face, start + nn, tsb, ah );
advances[nn] = ah;
}
}
@@ -161,7 +159,7 @@
FT_UShort aw;
-TT_Get_HMetrics( face, start + nn, check, lsb, aw );
+TT_Get_HMetrics( face, start + nn, lsb, aw );
advances[nn] = aw;
}
}
diff --git a/src/truetype/ttgload.c b/src/truetype/ttgload.c
index b2cab01..7923c6b 100644
--- a/src/truetype/ttgload.c
+++ b/src/truetype/ttgload.c
@@ -65,22 +65,16 @@
/*/
/* */
- /* Returns the horizontal metrics in font units for a given glyph. If */
- /* `check' is true, take care of monospaced fonts by returning the */
- /* advance width maximum.*/
+ /* Returns the horizontal metrics in font units for a given glyph. */
/* */
FT_LOCAL_DEF( void )
TT_Get_HMetrics( TT_Face face,
FT_UInt idx,
- FT_Bool check,
FT_Short* lsb,
FT_UShort* aw )
{
( (SFNT_Service)face-sfnt )-get_metrics( face, 0, idx, lsb, aw );
-if ( check face-postscript.isFixedPitch )
- *aw = face-horizontal.advance_Width_Max;
-
FT_TRACE5((
Re: [ft-devel] [PATCH] CJK Autohinter should not clump stems together when there are too many of them
Just I've committed your patch to git head, thanks! Regards, mpsuzuki r6144 wrote: 在 2011-04-20三的 19:57 +0900，mpsuz...@hiroshima-u.ac.jp写道： On Wed, 20 Apr 2011 12:35:29 +0200 (CEST) Werner LEMBERG w...@gnu.org wrote: One of my anxiety was that the priority to the black/white evenness can reduce the contrast of the complex glyph. Please find attached picture comparing the results by HeiseiMaruGo-W4 at 16pt @ 72dpi. In my personal impression, the legibility of the strokes in enclosed area (like 日 or 目) is not important, but the legibility of the longest stroke should be respected. Please let me know how your opinion. Thanks for reviewing. Do you have an idea how to increase the legibility of the longest strokes? Contrary to the proposed patch I think that this what you suggest is quite hard a job to achieve since you not only have to do feature analysis, e.g., mark horizontal stems which are surrounded by vertical stems like this |-| as `unimportant', but also distort the glyph accordingly so that `important' stems are aligned to the grid... I think what I requested (the longest stem should not be blurred) is difficult to co-exist with the proposed patch. So, if we find some comments that the rasterized result by 2.2.5 is too blurred and 2.2.4 is better, I will propose to revert the patch and discuss the appropriate condition to enable the feature. Fortunately, the proposed patch is not drastic. Yes, the long horizontal stroke at the middle of 量 often gets blurred by the patch. It would be better if we align the longest strokes first rather than doing it greedily, but after using this patch for two months, I think the current result is good enough for now. Thank you for reviewing the patch. r6144 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] [PATCH] CJK Autohinter should not clump stems together when there are too many of them
在 2011-04-20三的 19:57 +0900，mpsuz...@hiroshima-u.ac.jp写道： On Wed, 20 Apr 2011 12:35:29 +0200 (CEST) Werner LEMBERG w...@gnu.org wrote: One of my anxiety was that the priority to the black/white evenness can reduce the contrast of the complex glyph. Please find attached picture comparing the results by HeiseiMaruGo-W4 at 16pt @ 72dpi. In my personal impression, the legibility of the strokes in enclosed area (like 日 or 目) is not important, but the legibility of the longest stroke should be respected. Please let me know how your opinion. Thanks for reviewing. Do you have an idea how to increase the legibility of the longest strokes? Contrary to the proposed patch I think that this what you suggest is quite hard a job to achieve since you not only have to do feature analysis, e.g., mark horizontal stems which are surrounded by vertical stems like this |-| as `unimportant', but also distort the glyph accordingly so that `important' stems are aligned to the grid... I think what I requested (the longest stem should not be blurred) is difficult to co-exist with the proposed patch. So, if we find some comments that the rasterized result by 2.2.5 is too blurred and 2.2.4 is better, I will propose to revert the patch and discuss the appropriate condition to enable the feature. Fortunately, the proposed patch is not drastic. Yes, the long horizontal stroke at the middle of 量 often gets blurred by the patch. It would be better if we align the longest strokes first rather than doing it greedily, but after using this patch for two months, I think the current result is good enough for now. Thank you for reviewing the patch. r6144 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
