----- 元のメッセージ ----- | Akira TAGOH (tagoh@xxxxxxxxxx) said: | > One more thing is, current @fonts group has minimal sets of the | > packages only | > according to | > https://fedoraproject.org/wiki/PackageMaintainers/CompsXml#Fonts | > basically. so the language group may has some fonts packages to | > replace the | > _distribution-wide default fonts_ with the preferable typefaces. | | In what cases does it do this? My reading of the fonts groups were | that it | only ever installed additional fonts that were options to the | defaults, not | new defaults. (Especially since most any desktop user who installed a | langsupport group had @fonts installed anyway.) On some Indic languages say. for example, we have lohit-marathi-fonts, lohit-nepali-fonts and so on though, we don't install it by default because Marathi and Nepali uses the Devanagari-based script and basic functionality can be provided by lohit-devanagari-fonts IIRC. That looks like Chinese vs Japanese to me - IMHO we should install it by default as we do it for Chinese and Japanese, but anyway. | > if we also change the policy of "one font per scripts" to the "one | > font per | > languages" or so, it may affects to the disk size after the | > installation or iso | > size for Live and/or some spins perhaps. | | I'm willing to test to see how much space increase this causes - I | think | we're OK with both KDE and GNOME, unsure about XFCE/LXDE. Great. Thanks! | > | After looking at current comps, the language-specific | > | applications | > | might be an issue after removal, such as iok. also relevant bug | > | for | > | reference: https://bugzilla.redhat.com/show_bug.cgi?id=847500 | | iok is required by ibus-m17n; is that expected to change? Well, the point is that it breaks one-default-application policy. both iok and eekboard is a virtual keyboard application though, we already have one on GNOME say. unfortunately it doesn't support i18n well. so we still need iok and/or eekboard. We should get involved to improve i18n support but it's another story for long term because the upstream seems getting stuck on development so far. -- Akira TAGOH -- i18n mailing list i18n@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/i18n
