한글과 스페이스 순서가 바뀌는 문제

[diewelt]

slackware 14.2

** 문제점 ** X 윈도우상에서 한글 입력이 가능한 모든 입력창에서 한글 뒤에 스페이스를 붙이면 한글과 스페이스 순서가 바뀌는 문제가 발생합니다.

인터넷을 검색해 본 결과 이문제는 ibus-hangul의 문제로 알려져있는 것 같습니다. 다음 원인 항목을 참조하세요.

** 알려진 원인 ** 참고할 URL https://bugs.chromium.org/p/chromium/issues/detail?id=354495

What steps will reproduce the problem?

1. Install a Korean IME on Ubuntu (see http://starlinq.livejournal.com/2585.html )
2. Restart Chrome
3. Go to the omnibox
4. Switch to the Korean input mode (see the reference in #1). If you have only two input modes, Ctrl-Space will do the job.
5. Type a Korean word made up of two syllables or more followed by a space and another Korean syllable(e.g. '가나 다' by pressing 'rksk ek'. note the space after '나' or 'sk')

What is the expected output? What do you see instead?

Expected: '가나 다' is shown in the omnibox.

Actual: '가 나다' is shown in the omnibox. The space is after '가' instead of after '나'.

This is spun off from 353317. Bug 353317 is about a different (although seemingly related) symptom in Text area in web pages.

I found the root cause. The root cause is that ibus-hangul sends GTK's 'commit' signals in the wrong order when IBUS_ENABLE_SYNC_MODE=1. In the reported case, "가", " "(space), and then "나" are signaled in this order although it must be "가", "나" and then " " (space). So "가 나다" is the right result from our point of view. This is ibus-hanful's issue, I think.

There are two solutions.

1) Fix ibus-hangul so that it works with IBUS_ENABLE_SYNC_MODE=1. Other IMEs work fine with IBUS_ENABLE_SYNC_MODE=1.

2) Change the key event handling of Chrome Linux Aura so that it works with IBUS_ENABLE_SYNC_MODE=0. In this case, we have to live with the GDK event loop. (*1)

(*1) With IBUS_ENABLE_SYNC_MODE=0, IBus works in async mode. In async mode, gtk_im_context_filter_keypress() function returns immediately without waiting the completion of the key event processing, and it returns true which means the underlying IME has processed the key event. In case that the underlying IME didn't process the key event, gtk-ibus pushes the key event back to the GDK event loop. For the pushed-back key events, gtk_im_context_filter_keypress() returns false immediately. This is async mode of IBus, and if we use async mode, we have to live with the GDK event loop to process the pushed-back key events.

Thus, solution 2) will be a big design change for us.

** 특정 프로그램의 라이브러리 정보 ** leafpad 는 노트패드와 유사한 프로그램입니다. ldd which leafpad linux-vdso.so.1 (0x00007ffed4df1000) libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007fbd702ec000) libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007fbd70037000) libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007fbd6fe2a000) libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007fbd6fc04000) libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007fbd6f8df000) libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007fbd6f6bc000) libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007fbd6f32b000) libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007fbd6f116000) libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007fbd6eecb000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007fbd6ec7a000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fbd6e969000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fbd6e72c000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fbd6e490000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbd6e273000) libc.so.6 => /lib64/libc.so.6 (0x00007fbd6dea9000) libXinerama.so.1 => /usr/lib64/../lib64/libXinerama.so.1 (0x00007fbd6dca7000) libXi.so.6 => /usr/lib64/../lib64/libXi.so.6 (0x00007fbd6da98000) libXrandr.so.2 => /usr/lib64/../lib64/libXrandr.so.2 (0x00007fbd6d88d000) libXcursor.so.1 => /usr/lib64/../lib64/libXcursor.so.1 (0x00007fbd6d683000) libXcomposite.so.1 => /usr/lib64/../lib64/libXcomposite.so.1 (0x00007fbd6d481000) libpixman-1.so.0 => /usr/lib64/../lib64/libpixman-1.so.0 (0x00007fbd6d1db000) libEGL.so.1 => /usr/lib64/../lib64/libEGL.so.1 (0x00007fbd6cfb0000) libgbm.so.1 => /usr/lib64/../lib64/libgbm.so.1 (0x00007fbd6cda4000) libxcb-shm.so.0 => /usr/lib64/../lib64/libxcb-shm.so.0 (0x00007fbd6cba1000) libXrender.so.1 => /usr/lib64/../lib64/libXrender.so.1 (0x00007fbd6c998000) libGL.so.1 => /usr/lib64/../lib64/libGL.so.1 (0x00007fbd6c730000) libglapi.so.0 => /usr/lib64/../lib64/libglapi.so.0 (0x00007fbd6c501000) libXdamage.so.1 => /usr/lib64/../lib64/libXdamage.so.1 (0x00007fbd6c2ff000) libXfixes.so.3 => /usr/lib64/../lib64/libXfixes.so.3 (0x00007fbd6c0f9000) libX11-xcb.so.1 => /usr/lib64/../lib64/libX11-xcb.so.1 (0x00007fbd6bef7000) libxcb-glx.so.0 => /usr/lib64/../lib64/libxcb-glx.so.0 (0x00007fbd6bce1000) libxcb-dri2.so.0 => /usr/lib64/../lib64/libxcb-dri2.so.0 (0x00007fbd6badd000) libxcb-dri3.so.0 => /usr/lib64/../lib64/libxcb-dri3.so.0 (0x00007fbd6b8da000) libxcb-present.so.0 => /usr/lib64/../lib64/libxcb-present.so.0 (0x00007fbd6b6d8000) libxcb-randr.so.0 => /usr/lib64/../lib64/libxcb-randr.so.0 (0x00007fbd6b4cc000) libxcb-xfixes.so.0 => /usr/lib64/../lib64/libxcb-xfixes.so.0 (0x00007fbd6b2c5000) libxcb-render.so.0 => /usr/lib64/../lib64/libxcb-render.so.0 (0x00007fbd6b0bc000) libxcb-shape.so.0 => /usr/lib64/../lib64/libxcb-shape.so.0 (0x00007fbd6aeb9000) libxcb-sync.so.1 => /usr/lib64/../lib64/libxcb-sync.so.1 (0x00007fbd6acb3000) libxshmfence.so.1 => /usr/lib64/../lib64/libxshmfence.so.1 (0x00007fbd6aab1000) libXxf86vm.so.1 => /usr/lib64/../lib64/libXxf86vm.so.1 (0x00007fbd6a8ac000) libXext.so.6 => /usr/lib64/../lib64/libXext.so.6 (0x00007fbd6a699000) libX11.so.6 => /usr/lib64/../lib64/libX11.so.6 (0x00007fbd6a35c000) libxcb.so.1 => /usr/lib64/../lib64/libxcb.so.1 (0x00007fbd6a13d000) libXau.so.6 => /usr/lib64/../lib64/libXau.so.6 (0x00007fbd69f39000) libXdmcp.so.6 => /usr/lib64/../lib64/libXdmcp.so.6 (0x00007fbd69d34000) libdrm.so.2 => /usr/lib64/../lib64/libdrm.so.2 (0x00007fbd69b26000) librt.so.1 => /lib64/librt.so.1 (0x00007fbd6991d000) libgmodule-2.0.so.0 => /usr/lib64/../lib64/libgmodule-2.0.so.0 (0x00007fbd69719000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fbd69515000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fbd692f9000) libgthread-2.0.so.0 => /usr/lib64/../lib64/libgthread-2.0.so.0 (0x00007fbd690f7000) libffi.so.6 => /usr/lib64/../lib64/libffi.so.6 (0x00007fbd68eef000) libexpat.so.1 => /usr/lib64/../lib64/libexpat.so.1 (0x00007fbd68cc5000) libpng16.so.16 => /usr/lib64/../lib64/libpng16.so.16 (0x00007fbd68a93000) libharfbuzz.so.0 => /usr/lib64/../lib64/libharfbuzz.so.0 (0x00007fbd68815000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fbd68604000) libz.so.1 => /usr/lib64/../lib64/libz.so.1 (0x00007fbd683ef000) libm.so.6 => /lib64/libm.so.6 (0x00007fbd680e6000) libpcre.so.1 => /usr/lib64/../lib64/libpcre.so.1 (0x00007fbd67e72000) libmount.so.1 => /lib64/libmount.so.1 (0x00007fbd67c2c000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fbd679ec000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fbd677e7000) /lib64/ld-linux-x86-64.so.2 (0x000055f18b0ed000)

$ ls /var/adm/packages/gtk* /var/adm/packages/gtk+-1.2.10-x86_64-5 /var/adm/packages/gtk+2-2.24.30-x86_64-1 /var/adm/packages/gtk+3-3.22.4-x86_64-1 /var/adm/packages/gtk-xfce-engine-2.10.1-x86_64-2 /var/adm/packages/gtkmm-2.24.4-x86_64-1_SBo /var/adm/packages/gtkspell-2.0.16-x86_64-3

$ ls /var/adm/packages/qt* /var/adm/packages/qt-4.8.7-x86_64-4 /var/adm/packages/qtscriptgenerator-0.2.0-x86_64-2 /var/adm/packages/qtwebkit-2.3.4-x86_64-1

업그레이드 전 환경 (대체로 문제없이 사용하던 구성) /var/adm/removed_packages/gtk+2-2.24.20-x86_64-1 /var/adm/removed_packages/gtk+3-3.8.6-x86_64-1 /var/adm/removed_packages/qt-4.8.2-x86_64-4 /var/adm/removed_packages/ibus-1.5.3-x86_64_SBo /var/adm/removed_packages/ibus-hangul-1.4.2-x86_64-1_SBo /var/adm/packages/libhangul-0.1.0-x86_64-1

업그레이드 후 환경 (한글 입력은 되는데 마지막으로 입력된 한글과 스페이스 순서가 바뀌는 구성) /var/adm/packages/gtk+2-2.24.30-x86_64-1 /var/adm/packages/gtk+3-3.22.4-x86_64-1 /var/adm/packages/qt-4.8.7-x86_64-4 /var/adm/packages/ibus-1.5.14-x86_64-2_SBo /var/adm/packages/ibus-hangul-1.4.2-x86_64-1_SBo /var/adm/packages/libhangul-0.1.0-x86_64-1

업그레이드 후 환경 (한글 입력이 아예 안되는 구성) /var/adm/packages/gtk+2-2.24.30-x86_64-1 /var/adm/packages/gtk+3-3.22.4-x86_64-1 /var/adm/packages/qt-4.8.7-x86_64-4 /var/adm/packages/ibus-1.5.14-x86_64-2_SBo /var/adm/packages/ibus-hangul-1.5.0-x86_64-1_SBo /var/adm/packages/libhangul-0.1.0-x86_64-1

[choehwanjin]

모두 문제의 원인이 ibus-hangul이라고들 하니 살짝 안타깝긴 합니다.

ibus의 client는 DBUS로 통신하면서 이벤트 루프로 DBUS의 응답을 처리합니다. 따라서 ibus-hangul의 process_key_event 함수 안에서 여러 ibus 함수를 콜하면 그 리턴 값은 다음번 이벤트 핸들링때 처리 됩니다. 따라서 process_key_event 함수가 종료하기 전에 불린 update_preedit_text, commit_text 함수들에 대한 처리는 process_key_event 함수가 종료된 후 처리됩니다. 그러니까 이벤트 순서가 바뀌는 것입니다. 따라서 이런 방식으로는 SYNC모드를 구현할 수 없습니다.

원래 ibus의 디자인이 ASYNC 모드로 동작하도록 되어 있었는데, 나중에 SYNC모드를 구현하다보니 그렇게 되었다고 볼 수도 있긴합니다만, 근본적으로 입력기 이벤트 동작 방식에 대한 고민이 필요하다고 봅니다. 입력기 루틴이 같은 같은 프로세스 내에서 함수로 동작할 때는 위와 같은 방식도 작동하겠지만, 네트워크 통신으로 이루어질 때에는 아무래도 제약이 발생할 수 밖에 없지 않은가 생각합니다. process_key_event 함수가 bool 값이 아닌 수행해야하는 이벤트 리스트를 리턴하는 편이 더 적절하지 않을까 생각도 해봅니다.

이 문제를 해결하기 위해서는 ibus-hangul 안쪽에서 key event를 forwarding 해야 할 것 같은데, 이 방식이 또 문제를 일으킬까 걱정됩니다. 문제가 있다는 크롬 쪽에서는 gdk event 루프를 사용하지 않겠다는 것 같은데, 그러면 이 방식으로도 해결이 안될 것 같은 불길한 예상을 하게 됩니다. 아무튼 forwarding 방식으로 수정해 보겠습니다.

[diewelt]

ibus를 사용하기 시작한지 2년 정도 되는 것 같습니다. ibus 개발자나 ibus-hangul 개발자인 최환진님에게 항상 감사하고 있습니다. 윈도우를 아예 사용하고 있지 않고 있는데 한글을 쓰지 못한다면 윈도우로 돌아가는 것을 심각하게 고민해 봐야겠지요.

무료 한글 폰트 개발자 그리고 한글 입력기를 개발해주시는 모든 분들에게 감사하고 있습니다.

저도 한글 입력이 처리되는 방식을 잘 모르고, 구글 쪽에서도 마찬가지로 잘 몰라서 그러지 않았을까 싶네요. 내용을 알면서 잘못이 없는 모듈을 비난하지는 않을테니까요. 저도 단지 이 문제를 해결해주길 바라는 마음에 개발자님께 리포팅했던 것이니까요.

설명을 해주시니 내용을 잘 이해하지는 못하겠지만 ibus-hangul 문제가 아니라 ibus 자체의 근본적인 문제라는 것은 잘 알겠습니다. 그리고 개발자님께서 우려하시는 문제도 알겠습니다. 그렇다면 제 생각에도 ibus-hangul을 수정하지 않는 것이 나을 것 같기도 합니다. 물론 개발자님께서 결정하시는대로 따라야겠지만 말입니다.

제가 이 문제를 리포팅하고 아직 리포트하지 않은 내용이 있습니다. gtk 관련 패키지는 그대로 둔 상태에서 qt를 5.7로 업그레이드하고 ibus-hangul을 1.4.2로 했을 때 스페이스와 한글 순서가 바뀌는 문제는 사라집니다. 참고하시길 바랍니다.

아래는 현재 사용 중인 gtk와 qt 그리고 ibus 버전입니다.

/var/adm/packages/gtk+-1.2.10-x86_64-5 /var/adm/packages/gtk+2-2.24.30-x86_64-1 /var/adm/packages/gtk+3-3.22.4-x86_64-1 /var/adm/packages/gtkmm-2.24.4-x86_64-1_SBo /var/adm/packages/gtkspell-2.0.16-x86_64-3 /var/adm/packages/gtk-xfce-engine-2.10.1-x86_64-2

/var/adm/packages/qt5-5.7.0-x86_64-2_SBo /var/adm/packages/qt5-webkit-5.7.0-x86_64-1 /var/adm/packages/qtscriptgenerator-0.2.0-x86_64-2

/var/adm/packages/ibus-1.5.14-x86_64-2_SBo /var/adm/packages/ibus-hangul-1.4.2-x86_64-1_SBo

답변 감사드립니다.

새해 복 많이 받으십시오.

[sebuls]

MS 윈도 7 설치된 컴에 버추얼박스 설치하고, 데비안 9 설치 했습니다. 거기에 ibus-hangul 설치했는데 거기에서도 한글과 스페이스가 바뀌는 현상이 나타납니다.

[iljuLa]

데비안 9.3.0 LXDE 환경에서 여전히 같은 증상이 나타납니다. 신기한건 gnome 에서는 괜찮습니다. 설치한 ibus 버전은 1.5.0-2 입니다.

[changwoo]

현재 코드에 적용된 key event를 forwarding하는 workaround가 최근 GNOME 3.28.1의 mutter+wayland 환경에서 문제를 일으킵니다. 이쪽 클라이언트에서 "forward-key-event"를 처리하지 않아서이긴 하지만.

디버깅을 해 보면서 얼핏 이런 생각이 드는데 틀린 점이 있으면 알려주세요. preedit가 한글 "가"인 상태에서 1 키를 누르면 libhangul이 "가1" 문자열을 만들어 주는데요. 같은 상태에서 스페이스를 눌렀을 때도 libhangul에서 스페이스 문자가 뒤에 붙은 "가 "를 만들어 주면 따로 forward하고 할 필요는 없을 것 같은데 특별히 스페이스를 libhangul에서 그렇게 처리하지 않는 이유가 있나요?

[choehwanjin]

한글을 제외한 텍스트는 가능하면 커밋 스트링 대신 키 이벤트로 보내서 app이 이벤트로 처리할 수 있는 기회를 주려고 하고 있습니다. space나 tab을 커밋 스트링으로 변환하면 app 쪽에서는 아마도 이 키 이벤트처리를 못할 것입니다.

이런 여러가지 가능성들 때문에 forwarding 코드를 추가한 버전을 새로 릴리스하기가 좀 망설여 집니다.

[changwoo]

이런 여러가지 가능성들 때문에 forwarding 코드를 추가한 버전을 새로 릴리스하기가 좀 망설여 집니다.

네 저도 forwarding 넣지 않는데 찬성입니다. 뭔가를 하더라도 ibus 코드에서 방법을 찾아야 하지 않나 싶네요.

[choehwanjin]

https://github.com/ibus/ibus/issues/1847#issuecomment-368794155 위 링크를 보면 fujiwarat 씨는 forwarding 방식이 현재로서는 최선이라고 생각하는 것 같습니다.

[changwoo]

위 링크를 보면 fujiwarat 씨는 forwarding 방식이 현재로서는 최선이라고 생각하는 것 같습니다.

네 뭐 이상은 이상이고 당장 고칠 방법 찾기 어려우면 어쩔 수 없죠.. 데비안에서는 꽤 오래 git 버전 패키징하고 있는데 최근 mutter/wayland 말고 큰 문제는 없습니다.

[sebuls]

ibus 크롬, 페이스북이 함께 엮인 다음과 같은 문제는 어디를 어떻게 건드려야 하나요?

http://hamonikr.org/board_bFBk25/45850

[choehwanjin]

ibus-hangul 버전 - 1.5.0-3 (Manjaro repository 기준)

위 코드는 ibus-hangul 1.5.1에서 적용되었습니다. 1.5.1으로 사용해보셔야 할 것 같습니다.

[trainto]

현재 Ubuntu 20.04 사용 중입니다. Wayland 사용중인데 한글 <-> 스페이스 순서 바뀜 문제를 겪고 있습니다. 혹시 해결가능한 workaround 는 없을까요?

[choehwanjin]

현재 Ubuntu 20.04 사용 중입니다. Wayland 사용중인데 한글 <-> 스페이스 순서 바뀜 문제를 겪고 있습니다. 혹시 해결가능한 workaround 는 없을까요?

사용하시는 ibus-hangul 버전이 어떻게 되나요? 이 문제는 1.5.1에서 처리되었습니다. 혹시 아직도 wayland에서 문제가 있는 것인지도 모르겠습니다. wayland에서 "forward-key-event"를 제대로 처리하고 있는지 확인해보실 수 있을까요?

[changwoo]

현재 Ubuntu 20.04 사용 중입니다. Wayland 사용중인데 한글 <-> 스페이스 순서 바뀜 문제를 겪고 있습니다. 혹시 해결가능한 workaround 는 없을까요?

사용하시는 ibus-hangul 버전이 어떻게 되나요? 이 문제는 1.5.1에서 처리되었습니다. 혹시 아직도 wayland에서 문제가 있는 것인지도 모르겠습니다. wayland에서 "forward-key-event"를 제대로 처리하고 있는지 확인해보실 수 있을까요?

GNOME wayland의 forward-key-event 구현과는 별개로 현재 최신 릴리스된 GNOME 3.36은 문제 있습니다.

https://gitlab.gnome.org/GNOME/mutter/-/issues/948 (대략 요약하면 프로토콜 최적화를 하다가 사이드이펙트로 순서가 바뀌는 문제가 생겼습니다.)

피해가는 방법은 GTK_IM_MODULE=ibus 환경변수 설정하는 것이지요.

[trainto]

@choehwanjin 사용하고 있는 ibus-hangul은 1.5.3 으로 나옵니다.

@changwoo 말씀하신 대로 /etc/environment 에 GTK_IM_MODULE=ibus 설정 했더니 해당 현상은 아직까지는 발견되지 않고 있습니다. 감사합니다.

[demokritos]

어려워서 잘 모르겠습니다만, 이 문제를 해결하기 위해서 구현한 event forwarding의 부작용으로 #109 Gnome 40.0.0 wayland에서 스페이스와 엔터, 백스페이스가 입력되지 않는 문제가 생긴 것인가요? #109 는 event forwarding을 끔으로써 해결이 되었는데 한글과 스페이스 순서가 바뀌는 문제도 재현이 안 되네요. Gnome Xorg에서도 테스트해 보았는데 event forwarding 끈 상태에서 입력에 문제가 없어 보입니다. Qt 애플리케이션에서도 입력이 잘 됩니다.

[changwoo]

현상만 가지고 얘기를 하다 보니 이 이슈가 열려 있는 채로 한도 끝도 없이 다양한 얘기가 나오는 것 같은데요. 이 이슈는 닫고 원인별로 새로 취급했으면 좋겠습니다.

그 동안 밝혀진 것처럼 원인은 여러가지일 수 있고, 많은 부분이 밝혀지고 또 고쳐지기도 했는데요. 추가로 얘기가 나온다면 현상은 같더라도 완전히 다른 종류의 이슈일 겁니다.

[bsjeon]

제가 최근에 ibus 1.5.27에서 테스트했을 때, GTK_IM_MODULE=ibus ==> use_event_forwarding == false GTK_IM_MODULE=xim ==> use_event_forwarding == true 이 조건이면, #42, #109 문제가 없어졌습니다. gtk-demo, gtk3-demo, gtk4-demo 모두를 만족하는 조건이었습니다.

같은 이유로 구글 크롬 브라우저 wayland-gtk4 모드에서도 use_event_forwarding == false 이면 #109 문제가 없어졌습니다.

때문에, 상황에 따라서 가변적으로 use_event_forwarding 값을 적용할 수 있는 방법을 찾고 있었는데, 마침 #113 이 적절해 보입니다.

[HexagonWin]

오래된, 관련없는 문제를 다시 꺼내는 것 같아 죄송스럽습니다만,, Slackware 15.0에서 nabi 최신버전 (git 빌드) 구동할때 동일문제가 발생합니다. 다만 GTK+2와 GTK+3 기반 프로그램에서만 발생하며 xterm과 dtterm 등에선 정상적입니다. openoffice에서도 발생하네요..

안녕하세요 반갑습니다 ! -> 안녕하세 요반갑습니 다!

문제없이 구동되는 FreeBSD 13.2 환경에서 X11 포워딩을 통해 슬랙웨어쪽 디스플레이에서 나비를 구동해도 동일문제 발생합니다. X11 설정과 관련이 있는것으로 추정되는데 혹시 아시는 내용이 있을까요,,