Bug 66498

Created attachment 28814 [details]
yast2-000.png

screen shot to demonstrate the problem

I have no clue what those characters _should_ look like in the first place. 
But anyway this is a Qt or X problem. My first guess would be Qt. 

I'm not yet sure but I guess it is a font size problem.

We recently switched to use "Albany AMT" from the agfa-fonts during
the installation. This font is considerably smaller at 10 point than
the fonts we used before. For CJK we use a bitmap font (Gnu Unifont)
which has a fixed size and cannot scale. Previously the size of the
Gnu Unifont was close to the size of the font we used for Latin at
typical resolutions. Now it isn't.

Probably the clipping can be fixed by increasing the default font
point size from 10 to 11. I have not tried yet because I don't yet
know how to test this. Editing /tmp/.qt/qtrc in instsys and restarting
yast doesn't help because the edited /tmp/.qt/qtrc is overwritten
again with the original version.

It doesn't matter which language is selected in Linuxrc. Even if
Japanese is already selected in linuxrc and the YaST2 user interface
starts in Japanese, the Japanese characters are still clipped on the top.

This happens on buttons, in combo-boxes and in the list of the selectable
languages.

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

Maybe you could use Mikachan/Sazanami (mikachan-fonts.rpm and
sazanami-fonts.rpm) fonts -- they are scalable.

I am arguing for the use of scalable fonts for CJK in the installer
for a long time already.

problem 1):

we need to switch fonts in YaST2 because Qt can only use on font for
the Han region. For example we would need to switch between

   Sazanami  Japanese	
   FZSongTi  simplified Chinese
   FZMingTi  traditional Chinese

when the user changes languages. Such a change needs to be implemented
in YaST2. I think it is rather easy to do.

problem 2)

size: scalable fonts are quite a bit bigger than the Gnu Unifont
we are using now.

My opinion is that using scalable fonts for CJK is important in the
installer and we should really try to achieve that in the long run.

Since Japanese has borrowed a lot of Kanji from Chinese, Sazanami is at least a
beginning. Sites like http://zh.wikipedia.org/ display almost-completely in
scaled Sazanami if <your favorite web browser> is set to use it.
So if all Han fonts are merged into one, we do not need to switch. OTOH, that
creates a damn huge memory footprint.

Just trust me that Sazanami is not enough for Chinese.
It's *very* *far* from covering all what is necessary for Chinese.

FZSongTi from ttf-founder-simplified comes much closer to a font
covering everything for CJ (We can ignore K because we could use a
small Hangul only font for that, for example from the unfonts
package).

Anyway, even if we could find a single font which is complete enough
for both Japanese and Chinese, the style problem still remains.  For
Japanese and Chinese fonts with different style should be used for
best results. I.e. that we currently use only one font (The Gnu
Unifont) for both is just an ugly compromise.

Is it possible to use a small ttf fonts which covers a subset of CJK Unified Han
glyphs which is enough for insallation? One font can be used for all Chinese and
Japanese locales. For example CJK Unifont:

http://unifont.freedesktop.org/wiki/Software/CJKUnifonts

I think the style is not so important for installation.

It isnt' that much smaller than other CJK fonts like FZSongTi or
Sazanami:

mfabian@magellan:~/.fonts$ ll -h uming.ttf ukai.ttf
-rw-r--r--  1 mfabian suse 14M  2~ 28 15:52 ukai.ttf
-rw-r--r--  1 mfabian suse 14M  2~ 28 15:51 uming.ttf
mfabian@magellan:~/.fonts$ ll -h /usr/X11R6/lib/X11/fonts/truetype/FZSongTi.ttf
-rw-r--r--  1 root root 17M  2~ 22 18:53 /usr/X11R6/lib/X11/fonts/truetype/FZSongTi.ttf
mfabian@magellan:~/.fonts$ ll -h /usr/X11R6/lib/X11/fonts/truetype/sazanami-gothic.ttf
-rw-r--r--  1 root root 7.4M  1~ 19 06:17 /usr/X11R6/lib/X11/fonts/truetype/sazanami-gothic.ttf

Created attachment 29006 [details]
uming-not-enough-for-japanese.png

A Japanese sample text displayed with "AR PL ShanHeiSun Uni" (uming.ttf)
which shows that the font lacks many common Japanese glyphs.

The glyphs marked with red circles in the screen shot are common
Japanese glyphs which are not in "AR PL ShanHeiSun Uni", if you
look carefully, you can see that they are rendered by gedit with
a different font (IPAPGothic in my case) because they are missing
in "AR PL ShanHeiSun Uni".

So how about making a customized ttf font by combining several fonts together?
So we can use only one font for all language.

By the way, I want to replace the fonts from the packages  ttf-arphic-bkai00mp-20001125-588 ttf-arphic-gkai00mp-20001125-588 ttf-arphic-20001125-588 ttf-arphic-bsmi00lp-20001125-588 ttf-arphic-gbsn00lp-20001125-588  with the fonts from http://unifont.freedesktop.org/wiki/Software/CJKUnifonts.  But not for SuSE 9.3 anymore, for the next SuSE release after 9.3.  Anyway, these fonts don't help for the installer if we are looking for one font which can be used for both Japanese and Chinese.  FZSongTi seems to be better for Japanese, I'm not sure whether it is good enough for traditional Chinese though.

Olaf Dabrunz (CC:) and me discussed creating custom fonts quite often already.
Olaf even wrote some perl scripts to create a list of glyphs needed from the .po files
of YaST2. The idea was to feed these lists into a fontforge script which creates custom
fonts which only have the needed glyphs and nothing more. That would save a lot of space.

I think this idea is too complicated though, it is difficult to know in advance which
glyphs need to be displayed. The glyphs in the .po files of YaST2 are not the whole story,
additional glyphs could be required because of the output of some programs called
by YaST2 (That is just an example, we could think of quite a few cases where extra glyphs
would be necessary which cannot be found in the .po files).

Creating a single customized ttf fonts to cover both Japanese and (simplified) Chinese might not
be necessary, in that case we might be able to use FZSongTi unchanged.

Extending the fonts from

    http://unifont.freedesktop.org/wiki/Software/CJKUnifonts

to cover Japanese as well will be quite a lot of work. This might be a good idea for a
future version of SuSE Linux, but certainly not for SuSE 9.3.

For SuSE 9.3 we have to find a solution *now*. This is urgent!

Probably the quick and easy solution is to increase the size of the Latin font again.

Using FZSongTi.ttf is ok for both Simplified and Traditional Chinese, at least
for installation. If it's also ok for Japanese, then I propose to use it.

>It isnt' that much smaller than other CJK fonts like FZSongTi or
Sazanami

I meant "if you combine all CJK fonts into one" -- you would get a 32 MB file
probably, half of which is not used. Except if it's mmap'ed..

> you can see that they are rendered by gedit

Of course... the usual font is a serif/mincho/times_new_roman one while
IPAPGothic is a sans_serif/gothic/arial.

>additional glyphs could be required because of the output of some programs

Let alone a user name (Gecos) entirely made of CJK chars. (Yast prompts you to
add a user, you know.)

>Probably the quick and easy solution is to increase the size of the Latin font
again.

Yay, helps a lot to read, in any case.

Jan> I meant "if you combine all CJK fonts into one" -- you would get
Jan> a 32 MB file probably, half of which is not used. Except if it's
Jan> mmap'ed..

It is mmap'ed and that helps to reduce the amount of RAM required
by the application using the font.

But the instsys is also loaded into a RAM-disk, that means all
the fonts are also loaded into a RAM-disk. I.e. if you use a 32MB font,
you will at least need 32MB more RAM (because of the RAM-disk)
*and* the amount of RAM needed when YaST2 uses the font.

>I.e. if you use a 32MB font...

holy *. If I were to choose between CJK and the roman charset (which does not
have a zero), I'd go for roman :)
Well, let's hope that the bitmap font, which is used when the ncurses frontend
runs with ITE, does not use as much space.

Jan> Well, let's hope that the bitmap font, which is used when the ncurses
Jan> frontend runs with ITE, does not use as much space.

That is the Gnu Unicode Bitmap font, i.e. the same font we currently
use for CJK during the installation. Because it is a non-scaleable
bitmap font, it is fairly small. Scalable CJK fonts are huge.

In preparation to be able to use FZSongTi for CJK during the installation,
I enabled embedded bitmaps for all CJK languages in fontconfig:

-------------------------------------------------------------------
Thu Mar 03 18:36:21 CET 2005 - mfabian@suse.de

- Bugzilla #66498: use embedded bitmaps for Korean and Japanese
  as well, not only for Chinese as before to get readable Japanese
  and Chinese during the installation. The Latin fonts we currently
  use during the installation are smaller as before. With the
  Gnu Unifont currently used for CJK, this leads to clipping
  problems because this bitmap font cannot scale to a smaller size.
  When using TrueType fonts like FZSongTi for CJK, the clipping
  problems disappear because the font can scale down. But in such
  a tiny size, Japanese or Chinese is almost unreadable with
  Anti-Aliasing. It's better readable with the embedded bitmaps.

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

Steffen Winterfeld <snwint@suse.de> and me experimented today
with using FZSongTi for CJ and "Baekmuk Gulim" for K during the
installation. Because of the size, it seems not feasible to
add them to the inst-sys always.

But Steffen has already modularized instsys so that additions can
be loaded when certain languages are selected in the boot screen
of linuxrc.

The idea is to add FZSongTi and "Baekmuk Gulim" to inst-sys only of a
CJK language was selected in linuxrc. If not, the small Gnu Unicode
Font will be used as a fallback just as now.

We ran in to the problem that Qt in inst-sys refused to use FZSongTi
for CJK.  We found that the reason was that the locale use for YaST2
in inst-sys was *always* en_US.UTF-8 and then the locale specific
hacks Adrian added to our Qt package to select the right fonts could
not work.

That the locale was always set to en_US.UTF-8 was not intended, this
was apparently a bug. The locale was only read from the "contents"
file which contains the the default locale a DVD should set when the
user selects no language at all in linuxrc. This was always
en_US.UTF-8.

Marcus Schaefer just fixed this in YaST2 to prefer the locale of the
language selected in linuxrc.

Then YaST2 correctly uses FZSongTi for Chinese and Japanese and
"Baekmuk Gulim" for Korean if a CJK language is selected in linuxrc.

This increases the amount of RAM required for the installation,
but only if a CJK language is selected in linuxrc.

Should work like this in the Beta3.

FZSongTi scales and therefore the clipping problem disappears.

Nevertheless Japanese and Chinese characters are very difficult to
read in the tiny size currently used by default during the
installation because of the switch to the Agfa font (the same is true
for some other languages like Punjabi which have quite complicated
glyphs and dare therefore difficult to read because of the tiny size).

To improve the readability at least a bit, I submitted fontconfig
enabling embedded bitmaps always for CJK (comment #22).

But still Japanese is difficult to read.

It would help a lot if YaST2 could switch the font size on the fly.
This should not be very difficult in YaST2.

Gerd Knorr <kraxel@suse.de> had this idea. If keybindings
like for example Control-+ and Control-- in Firefox/Mozilla could
be introduced which would trigger a Qt call to change the fontsize
and redraw the screen, this would help a lot to make CJK better readable.

And, it would even make it possible to remove the clipping problem
even when no CJK language was selected in linuxrc and therefore the
Gnu Unifont is used. By increasing the font size one could make
the clipping problem disappear.

Adding Stefan Hundhammer <sh@suse.de> to CC: because changing font
sizes on the fly during the installation would be a new YaST2 feature.

>FZSongTi scales and therefore the clipping problem disappears.

What that's got to do with it? Why can't Qt get bitmapped fonts "in line" with
scaled fonts?

Yes, it is probably a Qt bug that Qt doesn't calculate the line
spacing according to the tallest font. If Qt would do that, it would
calculate the line spacing from the height of the Gnu Unifont because
this 16 pixel font is a lot taller than the current default font for
Latin ("Albany AMT") at 10 point.

I would see that as an improvement, but I am *sure* people would
start complaining about the too large line spacing for Latin then.

Apparently currently Qt calculates the line with according to the
Latin font. If fonts for other languages have a different size it will
look bad.

Anyway, the Gnu Unifont will always be 16 pixel tall and you cannot
help that something will look weird if you combine it with fonts of
very different size.

To make the scalable fonts look reasonably good next to the Gnu Unifont,
there is no other way but to scale them to approximately the same size.
Isn't that obvious?

Or, as we are trying now, avoid the Gnu Unifont and use scalable
fonts *always*. Which is the better solution in the long run
in my opinion.

I'm just thinking that why we don't use a bigger latin bitmap font to avoid the
clipping?
If FZSongTi will be used instead of the old bitmap font, we can still enlarge
the default font size to make it clearer to read.
Is that small font size necessary for the installation?

>I would see that as an improvement, but I am *sure* people would
>start complaining about the too large line spacing for Latin then.

Well, for people who install with a Latin-only font (European languagues +
american, basically) will never see a CJK character, thus, Qt [hopefully]
calculates only the line spacing amongst them, so it should look "normally
spaced" to them. 

>Apparently currently Qt calculates the line with according to the
>Latin font. If fonts for other languages have a different size it will
>look bad.

But only if you use CJK - and that's acceptable then, I hope.

>I'm just thinking that why we don't use a bigger latin bitmap font to avoid the
clipping?

AFAICS, we use a _scaled_ latin font.

Zhe> I'm just thinking that why we don't use a bigger latin bitmap font to
Zhe> avoid the clipping?

We use a scaled font for Latin for a long time already. Only for CJK
a bitmap font is still used during the installation.

Using a bigger size for the latin font would avoid the clipping of the
Gnu Unifont. That was one of my first suggestions and I still think it
is a good idea in addition to the extra hacks we did with using
FZSongTi. Because then it would look correct without clipping even if
no CJK-language is selected in linuxrc and a CJK-language is selected
later in the language selection screen at the beginning of the
installation.

Zhe> If FZSongTi will be used instead of the old bitmap font, we can still
Zhe> enlarge the default font size to make it clearer to read.

Yes, and I personally vote for a larger font for better readability.
I think the current Latin font is to small, even for latin and a CJK
font at that size is almost unreadable.  The size we had in SuSE 9.2
was OK in my opinion.

Zhe> Is that small font size necessary for the installation?

Adrian doesn't want to increase the Latin font size though, he said
that he reduced the font size on purpose.

If we cannot make the Latin font larger again by default, I thought it
might at least be a good idea if the user can select a larger
font. Therefore I suggested above to add a keybinding to change the font
size on user request.

Jan> Well, for people who install with a Latin-only font (European languagues +
Jan> american, basically) will never see a CJK character, thus, Qt [hopefully]
Jan> calculates only the line spacing amongst them, so it should look "normally
Jan> spaced" to them. 

No, that is not true because in the very first screen where you
see the list of languages you can see already CJK characters in
the names of the CJK languages. These are clipped at the top
because the line spacing is apparently calculated according to
the height of the Latin font. If it were calculated according to
the tallest glyphs on that page, i.e. the CJK glyphs, the line
spacing would be very big for latin and people would complain.

I don't know whether variable line spacing in Qt is possible at all,
but that would probably produce weird effects as well.

It can not look very nice if you mix glyphs of very different size,
no matter how do it.

For the language selection screen, use "best fit", i.e. 16 pixel so that
everything is displayed, then, if the user chooses Latin, fall back to
all-10pixel. (Better of course is always dynamic line spacing.)

>he reduced the font size on purpose

With what reason?

I also want to know.

Adrian, could you please tell us the reason to reduce the font size? Is it
possible to enlarge it a little?

Actually I like the smaller font. YaST is more usable with it. 
 
Having the font size customizable is a good idea, independent of the 
Asian vs. European language aspect. It would be a help for people with 
impaired vision, too. 

Zhe Su: the smaller font (still 10pt though) does help the layout in many YaST 
dialogs. Esp. the software selection got usable with 800x600 resolution again. 
 
We switched also to agfa-fonts because they have the same metrics as the 
standard MS fonts, which does help for document exchange and web page 
rendering. 

Adrian> the smaller font (still 10pt though)

The font which is now used ("Albany AMT") renders smaller in 10pt than
the font previously used ("SUSE Sans"/"Bitstreaam Vera Sans").  How
big a font really gets in 10pt apparently depends quite a bit on the
fonts design, there are significant differences between fonts from
different vendors.

Adrian> We switched also to agfa-fonts because they have the same metrics as the 
Adrian> standard MS fonts, which does help for document exchange and web page 
Adrian> rendering. 

But that has nothing to do with the installation. There are neither
documents nor web pages during the installation.

Since those new font sizes were way too small (close to illegible) anyway even 
for non-asian fonts, I had to increase them anyway. Now we get: 
 
    int normal  = 12; 
    int heading	= 14; 
 
    if ( x >= 800 && y >= 600 ) 
    { 
	normal	= 14; 
	heading	= 18; 
    } 
 
    if ( x >= 1024 && y >= 768 ) 
    { 
	normal	= 14; 
	heading	= 18; 
    } 
 
    if ( x >= 1280 && y >= 1024 ) 
    { 
	normal	= 16; 
	heading	= 20; 
    } 
 
    if ( x >= 1400 ) 
    { 
	normal	= 16; 
	heading	= 20; 
    } 
 
    if ( x >= 1600 ) 
    { 
	normal	= 18; 
	heading	= 24; 
    } 
 
    if ( x >= 2048 )	// Sounds futuristic? Just wait one or two years... 
    { 
	normal	= 20; 
	heading	= 28; 
    } 
 
 
% svn diff 
Index: YQUI_x11.cc 
=================================================================== 
--- YQUI_x11.cc (revision 21962) 
+++ YQUI_x11.cc (working copy) 
@@ -194,13 +194,13 @@ 
     int x = _default_size.width(); 
     int y = _default_size.height(); 
 
-    int normal  = 10; 
-    int heading        = 12; 
+    int normal  = 12; 
+    int heading        = 14; 
 
     if ( x >= 800 && y >= 600 ) 
     { 
-       normal  = 12; 
-       heading = 14; 
+       normal  = 14; 
+       heading = 18; 
     } 
 
     if ( x >= 1024 && y >= 768 ) 
@@ -211,8 +211,8 @@ 
 
     if ( x >= 1280 && y >= 1024 ) 
     { 
-       normal  = 14; 
-       heading = 18; 
+       normal  = 16; 
+       heading = 20; 
     } 
 
     if ( x >= 1400 ) 
 
 
Next time someone changes the default font to one that is smaller than the 
standards say it should, please _notify_ me. 

I DID tell you. 
 
and to solve this in a propper way we should adjust the dpy settings for the X 
server and not the font sizes. 

According to Marcus Schaefer, the dpi settings for the X server are
already set correcly for all monitors which can be detected correctly
with hwinfo, i.e. for almost all monitors.

The basic problem we're facing here (IMO) is that Microsoft turns on aliasing
only for fonts with sizes >= 14, thus things like Tahoma 10pt look very
different when you view on them on MS and Linux. In Linux, they seem smaller,
because of the antialiased edges (due to human perception).

#38 this is not true for installation it seems (and none of my systems) 
 
#39 this is complete off-topic. 

Adrian> #38 this is not true for installation it seems (and none of my systems)

I am right now installing a Beta2 where the dpi was set correctly.

Monitor is a "IIyama Vision Master Pro 450".

Have a look into /etc/X11/XF86config during the installation,
you should find a correct value of the option "DisplaySize".

With the code from comment #36, Stefan Hundhammer tried to increase
the font sizes for the installation. But apparently that didn't have
any effect. The font sizes during the installation in SuSE Linux 9.3
Beta3 look identical to the sizes in Beta2.

This bug also exists in Beta5.  
During installation, many Chinese characters are clipped. Some are translated 
wrong, which is misleading. 
Also some buttons like "help" are still in English. 
When using this system, there are too few Chinese language supporting. Most 
menus, bar, etc. are in English. Sometimes in English-Chinese combined format. 
Among these few Chinese characters, some are squares or rectangulars... 
I feel this system will be difficult for user to handle if he/she has a 
limited English knowledge. 

But one fact *related to the original problem*:

SUSE 9.1 has correct glyph heights!

Additional Comment #43 From Yi Xu 2005-03-22 04:04 MST

Yi> This bug also exists in Beta5.  During installation, many Chinese
Yi> characters are clipped.

Yes, Stefan Hundhammer wanted to increase the default font sizes
again, but apparently this didn't work.

When you select Chinese in linuxrc already, it will work though.  In
that case, a Chinese TrueType font is loaded as an extra into instsys
and used instead of the Gnu Unifont. Then Chinese characters will not
be clipped.

Yi> Among these few Chinese characters, some are squares or
Yi> rectangulars...

Can you give an example where this happens? KDE? Where?
Might be another Qt font bug. I would like to look into that.

Jan> But one fact *related to the original problem*:
Jan> SUSE 9.1 has correct glyph heights!

Accidentally because the Latin font size was bigger.  I still think we
should go back to the same font size as in SuSE 9.1/9.2.  And Stefan
Hundhammber agreed but somehow his change didn't work.

I'd like to say that the bug - which has been reported here (comment #0) has
been repaired already (Using the defualt linuxrc). All language names are
printed well in 9.3 RC1. So this bug should be CLOSED-FIXED.

If you feel that YaST strings aren't translated well, please, open a new bug and
assing it to translations because as I saw, a lot of strings weren't actually
translated to some languages, some languages have English helps (etc.).

>When you select Chinese in linuxrc already

In my case, I selected 1) Japanese, 2) selected it already in the bootloader.

>Might be another Qt font bug. I would like to look into that.

Nah, I just think that these glyphs are not defined -- there's a lot more
chinese chars than there are in latin, so it's "somewhat" justified that some
are missing. (Though, these missing glyphs in fonts should have been solved in
the last 10 years when these fonts were created :-)

>I'd like to say that the bug - which has been reported here (comment #0) has
been repaired already: All language names are printed well in 9.3 RC1.

Not only Listbox (as can be seen in comment #1) widgets were affected.

Andreas, please, could you tell us your resolution in this case of supported
languages?

Some languages are not translated well/enough some of them also sometimes print
quarters instead of characters. From my point of view - this cannot be fixed for
9.3 because we didn't resloved who is responsible for these many bugs.

Actually, more bugs are beeing taken through but it doesn't seem that any bug is
going to be fixed.

Thank you for your time

Coolo, why did you reassign this issue back to yast2-maintainers - without any 
comment whatsoever? 
 
No matter what font is chosen, if those widgets do their font rendering wrong 
or if they have the wrong font metrics, this is a Qt bug. YaST2 is just an 
application that USES those widgets. 
 
Please stop playing Bugzilla ping-pong. 

"Yes, Stefan Hundhammer wanted to increase the default font sizes 
again, but apparently this didn't work." 

Jan> In my case, I selected 1) Japanese, 2) selected it already in the bootloader.  If you do that, you will get a Japanese TrueType font and won't see any clipping. If this doesn't work for you, your Beta is too old. This definitely works.

Well, Comment #0 applied to B1 and B3. Dunno who changed it to B5. If version was changed, we have a button called "Copy to new".

Jan> Nah, I just think that these glyphs are not defined -- there's a lot more Jan> chinese chars than there are in latin, so it's "somewhat" justified that some Jan> are missing. (Though, these missing glyphs in fonts should have been solved in Jan> the last 10 years when these fonts were created :-)  Nonsense! In the Instsys we are using either the Gnu Unifont (If you do not select any CJK language in linuxrc) or, if you select Chinese in linuxrc, we use FZSongTi. Both are complete for Chinese. FZSongTi is commercial, high quality TrueType font.  And, if I understood Yi Xu right, she complained about squares when using the system *after* the installation:  Yi> When using this system, there are too few Chinese language supporting. Most  Yi> menus, bar, etc. are in English. Sometimes in English-Chinese combined format.  Yi> Among these few Chinese characters, some are squares or rectangulars...   After the installation, good, complete Chinese fonts should be available.  For example FZSongTi. If they are not used, something is wrong.  Therefore I would like to know how to reproduce that.  But that would be a completely different problem, this bug is about clipped fonts in the *installation*!

(In reply to comment #51) 
> "Yes, Stefan Hundhammer wanted to increase the default font sizes  
> again, but apparently this didn't work."  
 
There had been an unrelated bug that is fixed by now. 
But that approach was only a very limited workaround to begin with. 
It should be somewhat improved with recent versions (Beta5/RC1), but there is 
no guarantee that this workaround will keep working, nor is it a real fix. 

At least we should fix the font clipping issue when selecting English in
isolinux but Chinese in YaST. Because most Chinese users won't select the
language in boot screen.

Yes, and I think the only way to achieve that *fast* is to go back
to the same font sizes as in SuSE 9.2.

Did anybody check with RC1? 
 
The default fonts are back to a reasonable size. That should at least 
alleviate this problem. 

I did, as I reported in comment #46.

Chinese seems to be usable for all the installation. No letters are turned into
rectangles.

The rectangles are not the problem! The problem is clipping!

Yes, in the screen shot in comment #1 you see some rectangles. But these
are for Punjabi, not for Chinese or Japanese. This was just because
a Punjabi font had not been added to instsys yet.

Created attachment 32565 [details]
yast2-000.png

screen shot RC1. 1024x768. No language selected in linuxrc.

You can see that Japanese, Chinese, and Korean characters are clipped at the
top because they
are considerably taller than the Latin characters. And they cannot scale down
because the Gnu Unifont bitmap font is used (fixed size of 16x16 pixels for
CJK).

For comparison, the Japanese string should look like this: 日本語　

Compare with the screenshot, you see that the top part is missing.
This problem becomes worse when you select Japanese and look at the
help text (Help button at the lower left). You will see that
the lines overlap.

Created attachment 32567 [details]
yast2-001.png

screen shot showing the overlap in the help text.

Stefan Hundhammer and me have tested now that the clipping problem
disappears when reverting to the "SUSE Sans" font for Latin for the
installation. "SUSE Sans" was the font used in SuSE Linux 9.1 and
9.2. When using this font, it still works together with the Gnu
Unifont without clipping.

We had changed to "Albany AMT" instead of "SUSE Sans" for 9.3, but as we have
seen "Albany AMT" doesn't work well together with the Gnu Unifont.
Probably because "Albany AMT" is quite a bit smaller at the same point size.
Mot likely this is some Qt rendering problem which we never noticed
until now because it happened to work fine with "SUSE Sans".

Reverted auto-font sizes (see comment #36) back to the 9.2 values to make sure 
everything fits on the screen again when we go back to the "SUSE Sans" font 
like in 9.2 

Checked in for RC2 - and thus fixed.

This bug happend again in SUSE 10.0 beta3. I noticed that bitmap font
newunifont.pcf.gz was used again instead of truetype font FZSongTi.ttf (it was
used  in 10.0 beta2 and early version).

I'll attach a screen shot for reference.

Created attachment 47704 [details]
Installation screen shot of SUSE 10.0 b3.

I cannot reproduce this. FZSongTi.ttf is used. See my attached screen shot
of 10.0 Beta3.

Did you remember to select Chinese in linuxrc?

Only if you select Chinese in linuxrc, the TrueType fonts will be loaded
into instsys.

Created attachment 47736 [details]
yast2-000.png

screen shot from SL 10 beta3 which shows that FZSongTi (embedded bitmaps)
is used.

If small resolutions (e.g. 800x600) are used and the TrueType fonts
are not there (because Chinese was not selected in linuxrc), there
are still clipping effects. This is the same as in SuSE Linux 9.3
and cannot be easily fixed.

When TrueType fonts are used there is no clipping.

With sufficiently large resolutions (1024x768 is enough for me), there
is no clipping even when bitmap fonts are used.

Yes. I'm sure that I selected Simplified Chinese in linuxrc.
Did you test 5CD version or DVD version?

I doubt that it's only a bug of 5CD version.

I tested the DVD version.

The screen show in comment #68 is a 800x600 screen shot.
It is hard to avoid the clipping problem on 800x600. Same problem
existed on 9.3. But 800x600 is hardly used anyway.

Created attachment 47752 [details]
yast2-000.png

Here is a 1024x786 screen shot, Chinese, Gnu Unifont.

No clipping.

Steffen Winterfeld <snwint@suse.de> told me that the CD version
doesn't have the CJK TrueType fonts in the instsys.

Add Rüdiger Oertel <ro@suse.de> to CC: to check whether there is
enough room on CD1 to add the CJK TrueType fonts to the instsys.

Steffen also told me that there is usually no reboot anymore
after CD1. That means that adding the fonts to the instsys is enough,
the rpm packages are not needed on CD1 in that case.
The rpm packages contain more fonts than necessary for an installation,
the fonts really needed for the installation are much smaller
than the complete rpm packages.

Mike> Steffen also told me that there is usually no reboot anymore

"usually" because whether a reboot after CD1 is necessary or not
now depends on whether CD1 can be unmounted which depends on the
amount of RAM in the machine. On machines with very little RAM,
it may not be possible to unmount CD1 and in that case there
may be a reboot.

>But 800x600 is hardly used anyway.

How do you know? Have you done an empirical analysis?

I have also been told that a reboot after CD1 is usually necessary on
SMP machines.

Mike> But 800x600 is hardly used anyway.

Jan> How do you know? Have you done an empirical analysis?

Maybe I should have better written "hardly usable". Many translations
don't fit on the buttons when 800x600 is used, using it should be
avoided by all means if possible.

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

ad comment 79: no, that's not true. So it would only hit people with less 
than 256MB RAM. 

Packages which do not need to be on CD1 but currently are:

mfabian@magellan:/mounts/machcd2/CDs/SUSE-10.0-CD-OSS-i386-Beta3/CD1/suse/noarch$ du -s -h -c CID-keyed-fonts-Wada-20021114-204.noarch.rpm baekmuk-2.1-422.noarch.rpm ifntchia-1.2.1-195.noarch.rpm ifnteuro-1.2.1-195.noarch.rpm intlfnts-1.2.1-195.noarch.rpm ttf-alee-1.7-6.noarch.rpm unfonts-1.0.20040813-6.noarch.rpm xfntjp-20020904-432.noarch.rpm xfntl2-1.0-673.noarch.rpm
15M	CID-keyed-fonts-Wada-20021114-204.noarch.rpm
19M	baekmuk-2.1-422.noarch.rpm
5.7M	ifntchia-1.2.1-195.noarch.rpm
212K	ifnteuro-1.2.1-195.noarch.rpm
12K	intlfnts-1.2.1-195.noarch.rpm
212K	ttf-alee-1.7-6.noarch.rpm
16M	unfonts-1.0.20040813-6.noarch.rpm
13M	xfntjp-20020904-432.noarch.rpm
120K	xfntl2-1.0-673.noarch.rpm
68M	合計
mfabian@magellan:/mounts/machcd2/CDs/SUSE-10.0-CD-OSS-i386-Beta3/CD1/suse/noarch$

Reasons why not:

CID-keyed-fonts-Wada-20021114-204.noarch.rpm
    only for printing, currently does not work with fontconfig/Xft2 anyway.

baekmuk-2.1-422.noarch.rpm
ifntchia-1.2.1-195.noarch.rpm
ifnteuro-1.2.1-195.noarch.rpm
intlfnts-1.2.1-195.noarch.rpm
xfntjp-20020904-432.noarch.rpm
xfntl2-1.0-673.noarch.rpm
    these are non-Unicode bitmap fonts. I can see no reason why
    they should be needed during the installation. YaST2 uses
    fontconfig/Xft2, it cannot use non-Unicode bitmap fonts anyway.

unfonts-1.0.20040813-6.noarch.rpm
ttf-alee-1.7-6.noarch.rpm
    scalable Korean Fonts. But we use use only the fonts from baekmuk-ttf for
    Korean during the installation.

By the way, xfntl2 should be completely dropped in my opinion.
Most of them are duplicates of fonts already in the xorg-x11 package.

Font packages which currently are *not* on CD1 but should be added
if possible:

mfabian@magellan:/mounts/machcd2/CDs/SUSE-10.0-DVD-Beta3$ du -s -h -c  */*/*/{fonts-arabic,indic-fonts,IPAGothic,ttf-founder-simplified}*.rpm
2.8M	CD1/suse/noarch/fonts-arabic-0.20040113-4.noarch.rpm
2.6M	CD1/suse/noarch/indic-fonts-2005.06.15-2.noarch.rpm
1.6M	CD1/suse/i586/IPAGothic-001.000-13.i586.rpm
1.6M	CD1/suse/x86_64/IPAGothic-001.000-13.x86_64.rpm
39M	CD1/suse/noarch/ttf-founder-simplified-0.20040419-6.noarch.rpm
47M	合計
mfabian@magellan:/mounts/machcd2/CDs/SUSE-10.0-DVD-Beta3$

IPAGothic was listed twice in the last comment because it is not noarch
-> subtract 1.6M -> only 45.5M total.

Font packages which *are* already on CD1 and should stay there:

mfabian@magellan:/mounts/machcd2/CDs/SUSE-10.0-CD-OSS-i386-Beta3/CD1$ du -s -h -c  */*/{sazanami-fonts,desktop-data-SuSE,baekmuk-ttf}*rpm
8.2M	suse/noarch/sazanami-fonts-20040629-7.noarch.rpm
26M	suse/noarch/desktop-data-SuSE-10.0-2.noarch.rpm
9.8M	suse/noarch/baekmuk-ttf-2.1-422.noarch.rpm
44M	合計
mfabian@magellan:/mounts/machcd2/CDs/SUSE-10.0-CD-OSS-i386-Beta3/CD1$

desktop-data-SuSE should stay because it contains Adrian's "SUSE*" fonts
which are currently used for Latin during the installation.

baekmuk-ttf fonts are currently used for Korean during the installation.

sazanami-fonts should stay because if we run into legal problems
with IPAGothic, it is easier to switch to the sazanami-fonts in instsys
if the package is already on CD1, we cannot forget it then.
But it can be removed if we are sure that there is no legal problem
with IPAGothic!

Looks like the space on CD1 is no problem. According to comment #83
and #86:

   - 68M
   + 47M
   =====
=  - 21M

I.e. we gain 21M on CD1, according to Steffen only around 15M are necessary
to add to instsys so we still save around 6M on CD1.

So we only have to make sure now that there are no legal problems.

The following fonts could possibly cause legal problems:

    1) IPAGothic

       only distributable together with grass. No problem in my opinion as 
       long as grass is "somewhere" on the media, does not have to be CD1.

    2) ttf-founder-simplified
       currently missing on the CD-set and on the OSS version.
       ttf-founder-simplified is licensed for use on "Novell products".
       Is the OSS version a "Novell product"?

In case we cannot use IPAGothic and/or ttf-founder-simplified for the
CD-set and the OSS version, we could use sazanami-gothic (for
Japanese) and the Arphic fonts (for Chinese) instead.  This would be a
huge loss of quality though.

I think the clipping issue should be fixed in any situation. No matter which
resolution is used and which font is used.

I have a suggestion to fix the clipping issue:

Find a minimal font size which won't cause clipping, then make sure the font
size won't smaller than the minimal size.

And I don't know whether ttf-founder-simplified and ttf-founder-traditional are
ok to be put into OSS version. If we could only put open source software into
OSS version, then we may not put these fonts in it. But IMO, these fonts are
very important for Chinese users. Without them OSS version would be almost
unusable for Chinese users.

Fedora includes a commercial Chinese font, so I think maybe we could put those
commercial fonts in openSUSE as well.

Zhe Su> I think the clipping issue should be fixed in any
Zhe Su> situation. No matter which resolution is used and which font
Zhe Su> is used.

Yes, but ultimately the clipping problem seems to be a Qt bug.

Zhe Su> I have a suggestion to fix the clipping issue:
Zhe Su> 
Zhe Su> Find a minimal font size which won't cause clipping, then make
Zhe Su> sure the font size won't smaller than the minimal size.

Yes, Stefan Hundhammer could make the default font size for
800x600 a bit larger, but this would increase the risk that
texts won't fit on buttons anymore, i.e. this trades one
clipping problem for another. The translators usually
do not know how much room is there for the translations,
in 800x600 many texts do not fit on the buttons already.

Zhe Su> And I don't know whether ttf-founder-simplified and
Zhe Su> ttf-founder-traditional are ok to be put into OSS version. If
Zhe Su> we could only put open source software into OSS version, then
Zhe Su> we may not put these fonts in it. But IMO, these fonts are
Zhe Su> very important for Chinese users. Without them OSS version
Zhe Su> would be almost unusable for Chinese users.

Yes, therefore I hope we can make sure that we are allowed to
include them.

Maybe you can ask Founder?

Zhe Su> Fedora includes a commercial Chinese font, so I think maybe we
Zhe Su> could put those commercial fonts in openSUSE as well.

This would be the best solution.

To clarify the license of the founder fonts and to find out
whether we are allowed to use them on openSUSE, I opened
another bug. See bug #113347.

ok, setup changed for beta4. 
OSS variant will have ttf-arphic* 
retail variant will have ttf-founder-simplified and ttf-founder-traditional 
(all these on CD1) 
 
CD1 has now additionaly "fonts-arabic", "indic-fonts" 
CD2 has now CID-keyed-fonts-Wada xfntjp xfntl2 unfonts ttf-alee ifntchia 
ifnteuro intlfnts baekmuk 
 
 

James - can I ask you to create a bug report with the remaining information and possibly a way to reproduce the problem without yast. Then you can close this bug as duplicate of that one. But this bug is far from a useable qt bug ;(

I think we can close this bug as fixed. Because we are using truetype cji fonts during installation.

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

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

What's the status on this? In 10.2, it's happening again.

Did you select Japanese or Chinese in linuxrc?

The default in the bootloader (that would be English), I did not get to see linuxrc, but X right away. The list has Western height, choosing some CJK here does not enlarge it.
Is that supposed to happen when selecting English in the loader?

Jan Engelhardt> The default in the bootloader (that would be English)

In that case you won't get scalable fonts for CJK, only bitmap fonts.

Jan Engelhardt> Is that supposed to happen when selecting English in
Jan Engelhardt> the loader?

Yes because Qt3 apparently has problems when mixing bitmap fonts and
scalable fonts. It happens to work at some sizes but it doesn't work
reliably.

Maybe this will be better with Qt4 but I don't think it is worth
putting effort into fixing this in Qt3.  When only scalable fonts are
used there is no such problem.  And scalable fonts are used for CJK if
a CJK language is selected in linuxrc.

Add Tejun Heo <teheo@novell.com> to CC:.