- openSUSE M17n

Why there are nonlatin fonts in /etc/fonts/conf.d/60-family-prefer.conf?
by JS 13 Jun '24

13 Jun '24

65-nonlatin.conf already exists. And some fonts appear in both files.

1 0

Wishlist
by Masaru Nomiya 19 Feb '23

19 Feb '23

Hello, Since the Corona outbreak, phishing spam from China and Russia has increased dramatically, and even when separated, those from China are Japanese e-mails encoded in Chinese character codes (gb2312, gbk), and I was having a hard time dealing with the same pattern from my Chinese friends. However, I found skf, which supports more character encodings than nkf, built and installed it, and now I can send spam from China to /dev/null perfectly with procmail's filters, which is a great help. Cf. https://osdn.net/projects/skf/releases/ I found that the skf package is provided by fedora, and with some modifications to the src.rpm file, I was able to install and use skf on Tumbleweed. However, I think it is better to use the official version, so I would like to ask you to create a skf package for us. Regards. --- ┏━━┓彡野宮賢 mail-to: m.nomiya+m17n @ gmail.com ┃＼／彡 ┗━━┛ "A bachelor’s degree still holds prestige as a ticket to the middle class, but its value has received increasing scrutiny. In the last several years, rising tuition and student loan debt have led more Americans to reconsider an investment in postsecondary education." -- Washington Post --

2 2

Maintainership for google-noto-fonts and Future Releases
by Gordon Leung 13 Jun '22

13 Jun '22

Hi Everyone, I have recently been updating google-noto-fonts so that new fonts and fixes from upstream can come through here. Since there is no dedicated package maintainer for google-noto-fonts I wonder if I could be made that maintainer. Though regardless of whether I get the user role or not; I will try to make at least one update every two months to ensure that new fixes and fonts continue to flow down. Also, upstream is developing some new QA and release tools to make the process of releasing new fonts less error prone (and maybe finally do regular releases?). They promise it may happen in the next couple of months to the end of the year. https://github.com/googlefonts/noto-fonts/issues/2270#issuecomment-10589515… Thanks, Gordon Leung

1 0

Fwd: Proposal: Using update-alternative to switch input method
by Marguerite Su 27 Feb '22

27 Feb '22

sorry I forgot to CC our mailing list. ---------- 转发的邮件 --------- 发件人： Marguerite Su <i(a)marguerite.su> 日期：2022年2月25日周五21:00 主题：Re: Proposal: Using update-alternative to switch input method 收件人：Takashi Iwai <tiwai(a)suse.de> And I can not find any documentation about the $HOME/.i18n usage on openSUSE, except this slide: https://www.slideshare.net/ftake/redesigning-inputmethod-launcher-and-manag… So I wonder do we really have any real usage of “.xim” or “.i18n”? It seems you defined lots of place where we can declare the INPUT_METHOD env. But which ones should I take it seriously? The sysconfig? the “.xim”? The “.i18n”? Or the /etc/X11/xim.d? And what’s the priority if I declare that nev everywhere? Marguerite Su <i(a)marguerite.su>于2022年2月25日周五20:49写道： > Takashi Iwai <tiwai(a)suse.de>于2022年2月25日周五20:05写道： > > I guess this could be simplified if we provide some rpm macro. >> Basically a similar setup has been done for /etc/X11/xim.d (even >> manually), and we may combine even both stuff in a single macro > > > I begin to understand your approach now. If you make the generator itself > as update alternative, the generator script will be very very easy: you > just need to print INPUT_METHOD=<your input method framework name>. But > since the update alternative approach involves many different files, I > don’t think any rpm macro is possible. And again, rpm macro for all IMFs > needs another new package. I added this new package to automatically > transfer the existing XIM works to systemd/wayland since Xorg will not go > away in the foreseeable future. You don’t need to heavily touch other > existing IMF packages. I don’t think a new package + heavy modifications > for all existing packages works better than my approach. > > But still, like the name says, an user environment generator can not work > as the 100% replacement for the xim script. We still need to write lots of > systemd stuff (targets and etc) to achieve the goals that were done via the > LibreOffice/gsettings hacks, if you want to end up to an IMF systemd > service > > Hm, then the question is whether we want to user leaving without >> language-specific IM when user installs in CJK locale (or anything >> else). Of course, they can install the stuff later at any time, but >> the point of having lang(x)-Provides or whatever meta data is just to >> "recommend" the installation of those packages for specific locales. >> A similar stuff could be implemented in patterns as well, but I feel >> that locale(x) makes maintenance easier. >> > > OFF TOPIC: where can I find how these Provides are used? In which package? > I used to investigate lots of packages and OBS settings, but I didn’t find > any clue about this mechanism :-( So I wonder maybe these Provides are > useless, but the person who sees them made it happen by manually adding > those packages to ISOs :-) > > >>

2 2

Proposal: Using update-alternative to switch input method
by Fuminobu TAKEYAMA 25 Feb '22

25 Feb '22

Hi Marguerite and all, Thank you for working to support IM on Wayland sessions. I see your systemd-inputmethod-generator. https://build.opensuse.org/package/show/M17N/systemd-inputmethod-generator It simply read a list of input methods and precedence from (/usr)/etc/X11/xim.d/en. I think it is ok nowadays since we do not need complex mechanisms provided by /etc/X11/xim anymore. But I'm wondering how about using `update-alternatives` instead of reading /etc/X11/xim.d/en. A benefit of using update-alternatives is users can choose an input method by `update-alternatives --config` or YaST. `update-alternatives` is also used to configure a default display manager. To use update-alternatives, firstly, we prepare: [1] /usr/lib/input-method/user-environment-generators/fcitx [2] /usr/lib/input-method/user-environment-generators/ibus And run `update-alternatives --install` during installation: update-alternatives --install \ /usr/lib/systemd/user-environment-generators/29-input-method-generator \ input-method-user-environment-generator \ /usr/lib/input-method/user-environment-generators/fcitx \ 25 The following symlink to one of above will be generated: /usr/lib/systemd/user-environment-generators/29-input-method-generator Note that if [1] and [2] does not contain any program, the file managed by `update-alternatives` can be /lib/environment.d/99-input-method.conf What do you think? If you plan to extend your input-method-generator so that it can read /etc/X11/xim.d/$LANG and/or ~/.i18n, etc., the current approach will be appropriate. a related report: https://bugzilla.opensuse.org/show_bug.cgi?id=1084804 Best regards, Fuminobu Takeyama

4 6

Re: Replacing Fcitx4 with Fcitx5 in Factory
by Fusion Future 04 Jan '22

04 Jan '22

On 2021/12/19 01:24, Nianqing Yao wrote: > Hi everyone, > > There's a input method framework called fcitx4 shipped with openSUSE Tumbleweed and Leap, but when the whole project turns to new fcitx5, fcitx4 seems to be abounded and outdated. As far as I know, fcitx5 only exists in i18n project on the OBS, not in the main OSS repo. Could it possible to replace fcitx4 with fcitx5 in factory's OSS repo? So that Tumbleweed and Leap will finally benefit from it. I agree with you. Fcitx 4 is outdated and openSUSE already has Fcitx 5 in M17N repo. Fcitx 5 is much more usable on Wayland and is mature enough for daily use. It should be pushed to Factory as soon as possible.

2 2

Promoting fcitx5 to Factory
by Shung-Hsi Yu 23 Apr '21

23 Apr '21

Hi, Fcitx 5 has been in the M17N project for more than a year now, and it has an 5.0.0 release in November last year. Perhaps it's time to promote it into the Factory, co-existing with Fcitx 4? My personal experience spanning over 2 weeks is that fcitx5 seems to be the only IME that works consistently on Sway (a Wayland window manager, also). IBus falls a bit short when used with Firefox and Telegram Desktop. Having fcitx5 in Factory would make Sway users' live a bit easier by making it available without an extra `zypper addrepo ...` step. Best, Shung-Hsi

5 5

Re: [opensuse-m17n] Input method launcher supporting Plasma Wayland
by Fuminobu TAKEYAMA 03 Jun '18

03 Jun '18

Hi, sorry for being late to reply I made time for investigation. > Why do we try im-chooser (https://pagure.io/im-chooser/)? As far as I remember, one of the reasons is that im-chooser/im-settings does not provide feature to pick an IMF according to the current local every time. It seems that it is working on Plasma Wayland session under Fedora 28 (but I don't know why). Also it provides extra features such as xim proxy, to switch IMF dynamically. > I did some research > https://wiki.gnome.org/Initiatives/Wayland/SessionStart > environment variable can be set with systemd. Thanks, interesting. I confirmed it works on Leap 15.0 even though no standard directories are provided by our systemd package. It seems that there are several limitations. The cause is that environment variables are set for each user session not for each desktop session. This means that - Users cannot change variables (e.g, GTK_IM_MODULE) depending on the kind of desktop environment (by using XDG_CURRENT_DESKTOP). - Users cannot use different IMF for each desktop session. - Users need to exit all the sessions (applications) on their host to apply changes of those environment variables (need restart their systemd user session) + d-bus API to apply the change is also available I need to learn about systemd user session more. BTW: We have only 12 days to submit proposal of speech at openSUSE.Asia 2018 https://events.opensuse.org/conference/summitasia18 Thanks, Fuminobu TAKEYAMA On 15/05/2018 12:22, Marguerite Su wrote: > Hi, > > I did some research > > https://wiki.gnome.org/Initiatives/Wayland/SessionStart > > environment variable can be set with systemd. > > I wonder if we can set the im variable like this? > > And can we write a bridge (inputmethodd) like this: > > export QT_IM_MODULE=inputmethodd > > and inputmethodd is the application actually calls fcitx, ibus based on user > selection, locale, system presets.... > > So we can just pass inputmethodd to X11 or wayland, and do the im related work > in inputmethodd itself. > > Marguerite > > Hillwood Yang <hillwoodroc(a)gmail.com <mailto:hillwoodroc@gmail.com>>于2018年5月 > 14日周一下午4:42写道： > > Hi Ftake, > > Why do we try im-chooser (https://pagure.io/im-chooser/)? > > Regards. > Hillwood Yang > > 在 2018-05-06日的 11:57 +0900，Fuminobu TAKEYAMA写道： > > Hi all, > > > > openSUSE Leap 15.0 starts to provides Plasma Wayland. However, no > > input method > > is not launched simply because it does not execute X11 init script > > (/etc/X11/xim) [1]. > > > > [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1084804 > > > > > > Do you know anyone who are working for this? > > > > If nobody is doing, I will restart to develop my new input method > > launcher, Chameleon Tongue [2], introduced at openSUSE.Asia 2015 [3]. > > During this Japanese spring vacation, I check and confirmed that > > it can support Wayland with a easy fix (by executing it from > > /etc/profile.d). > > > > [2] https://github.com/ftake/chameleon-tongue > > [3] > > https://www.slideshare.net/ftake/redesigning-inputmethod-launcher-and > > -management-system > > > > I hope I can integrate it into openSUSE by Leap 15.1 or 16.0. > > > > Best, > > Fuminobu TAKEYAMA > -- > To unsubscribe, e-mail: opensuse-m17n+unsubscribe(a)opensuse.org > <mailto:opensuse-m17n%2Bunsubscribe@opensuse.org> > To contact the owner, e-mail: opensuse-m17n+owner(a)opensuse.org > <mailto:opensuse-m17n%2Bowner@opensuse.org> > -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-m17n+owner(a)opensuse.org

1 0

[opensuse-m17n] Input method launcher supporting Plasma Wayland
by Fuminobu TAKEYAMA 14 May '18

14 May '18

Hi all, openSUSE Leap 15.0 starts to provides Plasma Wayland. However, no input method is not launched simply because it does not execute X11 init script (/etc/X11/xim) [1]. [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1084804 Do you know anyone who are working for this? If nobody is doing, I will restart to develop my new input method launcher, Chameleon Tongue [2], introduced at openSUSE.Asia 2015 [3]. During this Japanese spring vacation, I check and confirmed that it can support Wayland with a easy fix (by executing it from /etc/profile.d). [2] https://github.com/ftake/chameleon-tongue [3] https://www.slideshare.net/ftake/redesigning-inputmethod-launcher-and-manag… I hope I can integrate it into openSUSE by Leap 15.1 or 16.0. Best, Fuminobu TAKEYAMA -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-m17n+owner(a)opensuse.org

2 1

[opensuse-m17n] Drop ghostscript-cjk package?
by Takashi Iwai 05 Mar '18

05 Mar '18

Hi, there is a delete request for ghostscript-cjk, and I'd like to ask anyone still using / requiring this. It seems that the script has been already broken over ages. If there is any active user of it, please speak up. thanks, Takashi -- To unsubscribe, e-mail: opensuse-m17n+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-m17n+owner(a)opensuse.org

1 1