Created attachment 72418 [details]
Screeshot shows FZSongTi rendering effect on different hinting styles.

The effect is the same for Japanese and Korean as well.

The hinting has an influence on the character spacing, therefore the
CJK characters which should all have the same width, don't have the
same width anymore after the hinting, therefore the lines in ftview
have different length.

If this is bad, than it is bad for Japanese and Korean as well and
we should probably use

        <match target="font">
                <test name="lang" compare="contains">
                        <string>ja</string>
                        <string>zh</string>
                        <string>ko</string>
                </test>
                <edit name="autohint" mode="assign">
                        <const>false</const>
                </edit>
        </match>


instead of doing this only for a few Chinese fonts.

Apart from the problem with the spacing, I think that the glyphs
rendered with the autohinter look better than those rendered with the
autohinter turned off.

I compared with freetype2-2.1.9 on SuSE Linux 9.3.  You are right, our
freetype2-2.1.9 package didn't have the problem with the CJK glyph
widths.

The patch below fixes the pitch problem with CJK glyphs.

The packages are found on mbuilt/bari-tiwai-12.
The baseline-correction (ft2-autofit-03-latin-baseline.diff) is disabled there since this seems to have many side effects.  (Note that ft2-autofit-01-* and 03 are slightly fixed)

The wavy rendering problem appears specially with IPA fonts.  Maybe a dedicated tuning would be necessary for them...

Created attachment 72726 [details]
Fix for pitch problem with CJK fonts

Created attachment 72728 [details]
ftview screenshot with new freetype2 library.

I tested the new package, but the issue is still there. The right side of glyphs is still zigzag (See screenshot).

btw, I noticed that there is a new afcjk module in freetype2 cvs head, which is based on akito's patch for 2.1.9. Unfortunately, the new afcjk module has similiar issue as well.

I just wonder whether we should back port the new module into our package and fix it, so that we can submit the fix back?

Zhe Su> I tested the new package, but the issue is still there. The
Zhe Su> right side of glyphs is still zigzag (See screenshot).

As far as the width problem is concerned, I cannot see any difference between
the packages we currently have in STABLE and Takashi's packages
from mbuilt/bari-tiwai-12. When viewed with ftview, both
screen shots show exactly the same problem with the glyph widths.

It's because FZSonti has a strange unicode table...  A known problem?

Arphic fonts seem OK.

Takashi Iwai> Arphic fonts seem OK.

Yes, indeed. What is the problem with the unicode table of FZSongTi?

Some unicode char ranges included in FZSonti are not covered by ft2.  For example, 0x33xx-0x4bxx, 0xaxxx, 0xe[78]xx, etc.  Adding the missing ranges should fix the problem.

Changing Takashi's patch like this fixes the problem indeed:

diff -u /work/built/mbuild/bari-tiwai-12/ft2-autofit-02-cjk.diff ./ft2-autofit-02-cjk.diff
--- /work/built/mbuild/bari-tiwai-12/ft2-autofit-02-cjk.diff	2006-03-14 10:23:47.000000000 +0100
+++ ./ft2-autofit-02-cjk.diff	2006-03-14 14:37:01.000000000 +0100
@@ -402,9 +402,9 @@
 +
 +
 +static const AF_Script_UniRangeRec af_cjk_uniranges[] = {
-+	{0x3000, 0x31ff},
-+	{0x4e00, 0x9fff},
-+	{0xac00, 0xd7ff},
++	{0x3000, 0xd7ff},
++	{0xf900, 0xfaff},
++	{0xfe30, 0xfe6b},
 +	{0, 0},
 +};
 +

Fixed package submitted to STABLE, closing as FIXED:

-------------------------------------------------------------------
Tue Mar 14 14:38:57 CET 2006 - mfabian@suse.de

- Bugzilla #157441: FZSongTi.ttf contains a lot more (CJK)-glyphs
  than most other fonts, therefore we have to expand the cjk range
  in Takashi Iwai's "ft2-autofit-02-cjk.diff" to render these
  glyphs correctly as well.
- Bugzilla #157441: don't apply ft2-autofit-03-latin-baseline.diff
  as it has some side effects.

----------------------------------------------------------------------

Actually, CJK code range is much wider than that. Below is the range table in afcjk.c from freetype2 cvs head:

  static const AF_Script_UniRangeRec  af_cjk_uniranges[] =
  {
    { 0x0100,  0xFFFF },
    { 0x2E80,  0x2EFF },  /* CJK Radicals Supplement */
    { 0x2F00,  0x2FDF },  /* Kangxi Radicals */
    { 0x3000,  0x303F },  /* CJK Symbols and Punctuation */
    { 0x3040,  0x309F },  /* Hiragana */
    { 0x30A0,  0x30FF },  /* Katakana */
    { 0x3100,  0x312F },  /* Bopomofo */
    { 0x3130,  0x318F },  /* Hangul Compatibility Jamo */
    { 0x31A0,  0x31BF },  /* Bopomofo Extended */
    { 0x31C0,  0x31EF },  /* CJK Strokes */
    { 0x31F0,  0x31FF },  /* Katakana Phonetic Extensions */
    { 0x3200,  0x32FF },  /* Enclosed CJK Letters and Months */
    { 0x3300,  0x33FF },  /* CJK Compatibility */
    { 0x3400,  0x4DBF },  /* CJK Unified Ideographs Extension A */
    { 0x4DC0,  0x4DFF },  /* Yijing Hexagram Symbols */
    { 0x4E00,  0x9FFF },  /* CJK Unified Ideographs */
    { 0xF900,  0xFAFF },  /* CJK Compatibility Ideographs */
    { 0xFE30,  0xFE4F },  /* CJK Compatibility Forms */
    { 0xFF00,  0xFFEF },  /* Halfwidth and Fullwidth Forms */
    { 0x20000, 0x2A6DF }, /* CJK Unified Ideographs Extension B */
    { 0x2F800, 0x2FA1F }, /* CJK Compatibility Ideographs Supplement */
    { 0,       0 }
  };

And I'm still wondering whether it's better to upgrade our freetype2 package to the latest cvs head. I found that many serious fixes are missing in our package.

I'll give you feedback as soon as I evaluate freetype2 cvs head.

The upgrade at this stage must be a fairly exception.  What we are allowed to do is to apply (minimal) backport patches.

I also doubt that we will be allowed to update a very important, basic
package like freetype2 to CVS head now.  Who knows what will break
then?

If you find very important fixes in CVS head which obviously don't
break anything, we can apply them.

But please create new bugreports for each important fix.

(Closing this bugreport as FIXED).

I see.

I just tested freetype2 cvs head. The rendering effect of new autofit module looks better than our package.

I'll backport the new autofit module plus necessary fix to our package and report the patch to bugzilla asap.

Thank you!

Created attachment 72808 [details]
New autofit patch backported from freetype2 cvs head.

The attached patch is backported from freetype2 cvs head. It makes autohinting rendering effect much better. This bug is also fixed by it.

Please test the new patch attached in comment #20. Old ft2-autofit-* patches are obsoleted by it.

Created attachment 72830 [details]
autofit-takashi.png

screen shot with Takashi's autofit patches.

Created attachment 72831 [details]
autofit-upstream-cvs.png

screen shot with the patch from upstream cvs.

I think the screen shot with the patch from upstream CVS looks
a little bit better.

Package with the patch from comment #20 submitted to STABLE.

Closing as FIXED.

-------------------------------------------------------------------
Tue Mar 14 18:16:30 CET 2006 - mfabian@suse.de

- Bugzilla #157441: instead of Takashi's patches, use a patch
  from upstream CVS which renders slightly better.

-------------------------------------------------------------------

Hmm, that patch handles the whole unicode range 0x0100-0xffff as CJK.
I don't know whether it's intentional or a typo.  I hope this won't have regressions for non-CJK letters.

Created attachment 72883 [details]
new patch with correct code range.

I think it's better to remove that range. Just tested and the rendering quality wasn't affected by removing it.

The new patch is attached, please apply.

Agreed to remove it.  At least, non-CJK/latin letters default to the old behavior.

FIXED (submitted to STABLE):
-------------------------------------------------------------------
Wed Mar 15 16:02:12 CET 2006 - mfabian@suse.de

- Bugzilla #157441:  remove 0x0100-0xFFFF from CJK Unicode range,
  as it might cause side effects for non-CJK scripts.

-------------------------------------------------------------------

is this supposed to break non-chinese setups? my fonts look horrible with this patch applied. 

Can you post two screen shots (good and bad) and which font do you use?

Created attachment 76171 [details]
freetype-new-hintfull.png

Created attachment 76172 [details]
freetype-new-hintmedium.png

Created attachment 76174 [details]
freetype-new-hintnone.png

Created attachment 76176 [details]
freetype-old-hintfull.png

Created attachment 76177 [details]
freetype-old-hintmedium.png

Created attachment 76181 [details]
freetype-old-hintnone.png

The screen shots from comment #32 to comment #37 are created with

    xfd -fa "Albany AMT"

and editing ~/.fonts.conf to try different values of "hintstyle", e.g.:

     <match target="font" >
      <edit mode="assign" name="hintstyle" >
       <const>hintfull</const>
      </edit>
     </match>

The screen shots "freetype-new-*" are created with freetype2 packages
with the bugzilla-157441-autofit-cjk-cvs.patch patch applied.

The screen shots "freetype-old-*" are created with freetype2 packages
with that patch *not* applied.

Examining the screen shots in detail (e.g. with xmag) shows that
the rendering for the hint styles "hintfull" and "hintnone" is
not changed at all.

But the rendering for the hintstyle "hintmedium" is changed.

Without the patch, "hintmedium" rendered *exactly* the same as
"hintfull". I guess this was a bug, I don't think "hintmedium"
should render the same as "hintfull".

With the patch, the result using "hintmedium" is somewhere between
"hintfull" and "hintnone" (but rather close to "hintnone").  This is
probably correct.

*** Bug 162556 has been marked as a duplicate of this bug. ***

fonts-config packages submitted to NOARCH which sets
hinstyle=hintfull as the default in /etc/fonts/suse-hinting.

Is there some trick to getting that package to work? I built a package with that change, installed it, and reran SuSEconfig.fonts, but my fonts still look ugly. (I even tried rm'ing /var/cache/fontconfig/* and ~/.fonts.cache-2 and running SuSEconfig.fonts again, but that didn't help.)

The caches in /var/cache/fontconfig/* and ~/.fonts.cache-2 have no influence
on the hintstyle.

Dan> Is there some trick to getting that package to work? I built a package with
Dan> that change, installed it, and reran SuSEconfig.fonts, but my fonts still look
Dan> ugly.

After running SuSEconfig.fonts with the new fonts-config package installed,
you should have

    
        <!--
            Using the autohinter, hintstyle=hintfull and anti-aliasing.
            This is a good default for most fonts.
        -->
        <match target="font">
                <edit name="autohint">
                        <bool>true</bool>
                </edit>
                <edit name="hintstyle">
                        <const>hintfull</const>
                </edit>
                <edit name="antialias">
                        <bool>true</bool>
                </edit>
        </match>

in /etc/fonts/suse-hinting.conf (close to the top of that file).

If it still doesn't work for you, I guess you have a ~/.fonts.conf
file in your home directory which changes the hintstyle again.  The
hintstule set in the user specific file ~/.fonts.conf has higher
priority and overrides the system default.

I'm closing this bug as FIXED again, feel free to reopen if your ~/.fonts.conf
is not the problem.

I don't have a fonts.conf, but I think my problem now is part of bug 104365.