Mike FABIAN <mfabian@suse.de> さんは書きました:

UTUMI Hirosi <utuhiro78@yahoo.co.jp> さんは書きました:

...

I tested OpenSUSE 10.0 beta2. Most things are OK, but uim-anthy doesn't work for me. uim.spec doesn't register uim to gtk2-immodule properly.

[...]

You are right that updating of the gtk.immodules file should be moved to the "%post gtk2 section".

Done, see https://bugzilla.novell.com/show_bug.cgi?id=112931 -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Hi, --- Mike FABIAN <mfabian@suse.de> wrote:

UTUMI Hirosi <utuhiro78@yahoo.co.jp> さんは書きました:

...

- enable uim-m17nlib.

This is disabled on purpose on request of Zhe Su <zsu@novell.com> (SCIM author) because scim-m17n is also available. scim-m17n works just fine and supporting m17n in uim as well is therefore not necessary and only makes it more confusing for beginners.

Then we should remove uim-anthy/uim-canna/uim-skk (or uim itself), because scim supports anthy/canna/skk. We can remove scim-uim for Japanese, then UIM packages will be optional. Beginners will not be confused. (Mandriva's uim packages support m17nlib.) I think scim-anthy and scim-uim-anthy will confuse beginners. scim-anthy is good enough for most users.

...

- add uim-qt. - # uim-qt was merged into uim. - add uim-qt-applet. - # we need to enable uim-qt-applet for uim-qt.

It is probably too late to add this for SuSE Linux 10.0, I may not be allowed to add new sub-packages anymore.

ok.

...

After you update uim, remove ~/.uim.d/ please. (to initialize uim configurations)

I do no have a ~/.uim.d/, only ~/.uim

Run uim-pref-gtk and change some settings please. It will make ~/.uim.d/.

...

SUSE installs scim-uim for the default Japanese input. I think scim-anthy is better.

No, scim-uim is not the only default Japanese input, *both* scim-uim *and* scim-anthy are installed by default.

SUSE 10.0 beta2 didn't install scim-anthy for Japanese. (Is it my mistake ?) Thanks. Hirosi __________________________________ Save the earth http://pr.mail.yahoo.co.jp/ondanka/

Hi, --- Mike FABIAN <mfabian@suse.de> wrote:

UTUMI Hirosi <utuhiro78@yahoo.co.jp> さんは書きました:

...

We can remove scim-uim for Japanese, then UIM packages will be optional. Beginners will not be confused.

And maybe include the uim packages on the CDs/DVD but not install them by default?

Yes.

I'll consider that for the next SuSE Linux version after 10.0.

:-)

...

...

No, scim-uim is not the only default Japanese input, *both* scim-uim *and* scim-anthy are installed by default.

SUSE 10.0 beta2 didn't install scim-anthy for Japanese. (Is it my mistake ?)

Apparently it is only on the DVD but missing on the CDs.

This must be a mistake, thank you for reporting this!

I understand. I'll go to bed. Thanks! Hirosi __________________________________ Save the earth http://pr.mail.yahoo.co.jp/ondanka/

Mike FABIAN <mfabian@suse.de> さんは書きました:

UTUMI Hirosi <utuhiro78@yahoo.co.jp> さんは書きました:

...

...

...

SUSE 10.0 beta2 didn't install scim-anthy for Japanese. (Is it my mistake ?)

Apparently it is only on the DVD but missing on the CDs.

This must be a mistake, thank you for reporting this!

I understand.

Fixed for Beta4. In Beta4, scim-anthy should be on the CDs as well, not only on the 9 GB DVD.

The bug still persisted but should be finally fixed for RC3 now, see: http://bugzilla.novell.com/show_bug.cgi?id=116730 -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Takashi Iwai <tiwai@suse.de> さんは書きました:

...

SUSE 10.0 beta2 didn't install scim-anthy for Japanese. (Is it my mistake ?)

Might be. Anyway, it's already fixed on beta3.

No, it is still the same on beta3: "scim-anthy" is included on the 9GB DVD but neither on the 5GB DVD nor on the CD-set. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

UTUMI Hirosi <utuhiro78@yahoo.co.jp> さんは書きました:

--- Mike FABIAN <mfabian@suse.de> wrote:

...

The easiest way to disable embedded bitmaps for Japanese would be to remove the line

<string>ja</string>

in /etc/fonts/suse-pre-user.conf.

ok. (but does it disable hinting? Hinting is not good for CJK [or square] characters)

It worked quite well as long as Akito San's patch was included, the IPA fonts were rendered nicely as well. As this patch is gone now, I disabled the hinting for the IPA fonts. See this part in /etc/fonts/suse-pre-user.conf: <!-- Since we updated to freetype 2.1.10, the patch from http://www.kde.gr.jp/~akito/patch/freetype2/2.1.7 could not be applied anymore. Unfortunately the rendering quality of CJK fonts suffered a lot because of this update. The most extreme loss of rendering quality happened for the IPA fonts. See also http://bugzilla.novell.com/show_bug.cgi?id=105626 For other CJK fonts it is not that bad and on top of that most other CJK fonts have a wide range of embedded bitmaps which are used by default. And for big sizes, where there are not bitmaps anymore, the rendering quality is good anyway. As a workaround, switch of the hinting by setting hintstyle=hintnone for the IPA fonts: --> <match target="font"> <test name="family"> <string>IPAMincho</string> <string>IPAGothic</string> <string>IPAPMincho</string> <string>IPAPGothic</string> <string>IPAUIGothic</string> </test> <edit name="hintstyle"> <const>hintnone</const> </edit> </match> We could easily disable the hinting for all CJK fonts with something like this: <!-- Hinting for CJK fonts in freetype doesn't yet work as well as for Latin fonts. But our freetype package has the patch from http://www.kde.gr.jp/~akito/patch/freetype2/2.1.7 applied which improves the hinting results for CJK fonts a lot. If you are using a freetype package without that patch you may prefer to switch off hinting by setting hintstyle=hintnone for CJK fonts. This can be achieved by using the following rule: <match target="font"> <test name="lang" compare="contains"> <string>ja</string> <string>zh</string> <string>ko</string> </test> <edit name="hintstyle" mode="assign"> <const>hintnone</const> </edit> </match> --> which is also in /etc/fonts/suse-pre-user.conf but currently commented out because for the other CJK fonts the hinting appears to be not that bad as for the IPA fonts.

...

And I guess that a font designer who includes embedded bitmaps in his fonts does this because he believes they give better results than the outlines. If the font designer doesn't think so, why include embedded bitmaps at all?

MS Windows 9x can't show antialiased outlines, so MS fonts/IPA fonts include embedded bitmaps to show small characters clearly. But freetype2 shows outlines beautifully, so I think outlines are better than bitmaps.

Even on MS Windows XP, anti-aliasing is enabled by default only for sizes > 18 pixels. I didn't test the Japanese fonts but I verified that this is indeed the case for western fonts. To switch on anti-aliasing, the user has to select "Clear Type" in the Windows control centre manually. That means, the default look and feel of MS Windows XP looks rather bitmap like. These are not really bitmaps but outlines rendered without anti-aliasing with very high quality, which achieves practically the same quality as hand tuned bitmaps. Recently, during the beta phase of SuSE Linux 10.0, I made this the default for a selected list of fonts which have good byte code. See the following part of /etc/fonts/suse-pre-user.conf: <!-- ************************************************************ --> <!-- Hinting and antialiasing --> <!-- ************************************************************ --> <!-- Fonts which have high quality byte code interpreter instructions can look very good in small sizes when rendered in black and white (antialias=false) using the byte code interpreter (autohint=false). The results look as good as high quality bitmap fonts. On the other hand, most Fonts do not have good byte code interpreter instructions and look *very* ugly when rendered like this. I.e. for most fonts autohint=true and antialias=true gives best results. For fonts which do have good byte code instructions, it seems to be a matter of taste. Most users apparently do not like the bitmaps no matter how good they are and prefer to render these fonts with anti-aliasing as well. When rendering fonts which do have good byte code with anti-aliasing (antialias=true), the byte code apparently doesn't help much, to the contrary, it produces strange rendering artifacts. Therefore it is usually better to always use the autohinter (autohint=true) when rendering with anti-aliasing. --> <!-- Using the autohinter and anti-aliasing. This is a good default for most fonts. --> <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> <!-- The following rule sets up black and white rendering with the byte code interpreter for a small list of fonts which are known to have good byte code and give bitmap quality results at small sizes. The pixelsize limit is set to '0' though, which effectively disables this rule by default because most users don't like that bitmap look and feel. If you like a bitmap look and feel of your desktop, copy this rule into your ~/.fonts.conf file and replace the '0' with non-zero pixelsize limit. Using '18' as the pixelsize limit is a good choice if you have the fonts in this list installed and like a bitmap look and feel. --> <match target="font"> <test name="family"> <string>Andale Mono</string> <string>Arial</string> <string>Comic Sans MS</string> <string>Georgia</string> <string>Impact</string> <string>Trebuchet MS</string> <string>Verdana</string> <string>Courier New</string> <string>Times New Roman</string> <string>Tahoma</string> <string>Webdings</string> <string>Albany AMT</string> <string>Thorndale AMT</string> <string>Cumberland AMT</string> </test> <test name="pixelsize" compare="less_eq"> <double>0</double> <!-- use a non-zero pixel size to enable this rule --> </test> <edit name="autohint"> <bool>false</bool> </edit> <edit name="antialias"> <bool>false</bool> </edit> </match> I used 18 pixel as the limit, just as on MS Windows. A handful of users had requested to make this the default, but after I had done this, I received many complaints from other users, therefore I disabled this rule again by setting the limit to 0 pixels. Although this style is the default on MS Windows XP, most Linux users apparently do not like it.

...

I want to disable embedded bitmaps for Japanese by default only if we are *sure* that the majority of users prefers the outlines. How to find out?

suse-linux-ja?

I'll ask there. -- Mike FABIAN <mfabian@suse.de> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。

Hi, --- Mike FABIAN <mfabian@suse.de> wrote:

for another reason to stay with enabling the embedded bitmaps see

http://bugzilla.novell.com/show_bug.cgi?id=105626

Wavy rendering with freetype2.1.10 and IPA fonts

I know it. :-p Sometimes IPA font rendering is broken... Maybe 'fc-cache -f /usr/X11/lib/X11/fonts/truetype/' will solve it (?)

Until we updated to freetype 2.1.10 we used a patch from

http://www.kde.gr.jp/~akito/patch/freetype2/

to improve the rendering for CJK fonts.

I hope this patch can be adapted for freetype 2.1.10,

I don't think it will merged into freetype2. I had told it to Werner: http://lists.gnu.org/archive/html/freetype-devel/2004-09/msg00004.html Thanks. Hirosi __________________________________ Save the earth http://pr.mail.yahoo.co.jp/ondanka/