Bugzilla – Bug 66498
Japanese, Chinese, and Korean characters clipped during installation
Last modified: 2007-06-05 11:09:17 UTC
See attached screen shot. Japanese, Chinese, and Korean characters are clipped during the installation.
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:.