Некоторые приложения X принимают мои нелатинские символы, некоторые игнорируют их

389
einpoklum

Я использую среду X с двойной раскладкой клавиатуры: us,il. Теперь в некоторых моих приложениях и в ilмакете ивритские символы не регистрируются, а знаки препинания - нет. В других приложениях ивритские символы хорошо регистрируются и добавляются к любому тексту, который я набираю. Английская раскладка отлично работает. Я предоставлю полную информацию о моей конфигурации ниже.

Мои вопросы: почему это происходит? И что еще более важно, как я могу это исправить / обойти и заставить все приложения также принимать ивритские символы?

Подробности о моей настройке

  • Физическая раскладка клавиатуры: стандартная US 104-клавишная (как эта ).
  • Распространение ОС: Devuan 2.0 ASCII (~ = Debian 9.0 Stretch)
  • Конфигурация XKB:

    $ setxkbmap -query rules: evdev model: pc105 layout: us,il variant:, options: grp:alt_shift_toggle,grp_led:scroll 
  • Окружение рабочего стола: это происходит со мной как с Cinnamon, так и с LXQt; еще не пробовал других.

  • Приложения, отклоняющие ивритские символы: Cinnamon's Alt + F2 launcher; Leafpad; GEdit, xterm.
  • Приложения, принимающие ивритские символы: KWrite, GNOME Terminal, LibreOffice, Firefox, Kolourpaint, lxterminal, Konsole.

xev выход

Вывод при нажатии aна клавиатуру:

KeyRelease event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369470632, (96,-25), root:(146,62), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False  KeyPress event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369474392, (96,-25), root:(146,62), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) "a" XFilterEvent returns: False 

Выход при переключении раскладки клавиатуры:

KeyPress event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369547896, (75,-23), root:(125,64), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes:  XFilterEvent returns: False  KeyPress event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369548008, (75,-23), root:(125,64), state 0x8, keycode 62 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XKeysymToKeycode returns keycode: 50 XLookupString gives 0 bytes:  XFilterEvent returns: False  PropertyNotify event, serial 34, synthetic NO, window 0x7e00001, atom 0x176 (XKLAVIER_STATE), time 369548013, state PropertyNewValue  PropertyNotify event, serial 34, synthetic NO, window 0x7e00001, atom 0x176 (XKLAVIER_STATE), time 369548013, state PropertyNewValue  KeyRelease event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369548072, (75,-23), root:(125,64), state 0x2008, keycode 62 (keysym 0xfe08, ISO_Next_Group), same_screen YES, XKeysymToKeycode returns keycode: 50 XLookupString gives 0 bytes:  XFilterEvent returns: False  KeyRelease event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369548168, (75,-23), root:(125,64), state 0x2008, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes:  XFilterEvent returns: False 

Вывод при aповторном нажатии на клавиатуре (эта клавиша также соответствует еврейской букве shin,,):

KeyPress event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369560440, (75,-23), root:(125,64), state 0x2000, keycode 38 (keysym 0xcf9, hebrew_shin), same_screen YES, XLookupString gives 0 bytes:  XFilterEvent returns: False  KeyRelease event, serial 34, synthetic NO, window 0x7e00001, root 0x43, subw 0x0, time 369560504, (75,-23), root:(125,64), state 0x2000, keycode 38 (keysym 0xcf9, hebrew_shin), same_screen YES, XLookupString gives 0 bytes:  XFilterEvent returns: False 

xmodmap -pke выход

Часть вывода xmodmap -pke:

... etc. etc. ... keycode 24 = q Q slash Q U05C2 keycode 25 = w W apostrophe W U05C1 keycode 26 = e E hebrew_qoph E U05B8 keycode 27 = r R hebrew_resh R U05B3 keycode 28 = t T hebrew_aleph T keycode 29 = y Y hebrew_tet Y U05F0 keycode 30 = u U hebrew_waw U U05B9 keycode 31 = i I hebrew_finalnun I keycode 32 = o O hebrew_finalmem O keycode 33 = p P hebrew_pe P U05B7 keycode 34 = bracketleft braceleft bracketright braceright U05B2 keycode 35 = bracketright braceright bracketleft braceleft U05BF keycode 36 = Return NoSymbol Return keycode 37 = Control_L NoSymbol Control_L keycode 38 = a A hebrew_shin A U05B0 keycode 39 = s S hebrew_dalet S U05BC keycode 40 = d D hebrew_gimel D keycode 41 = f F hebrew_kaph F keycode 42 = g G hebrew_ayin G U05F1 keycode 43 = h H hebrew_yod H U05F2 keycode 44 = j J hebrew_chet J U05B4 keycode 45 = k K hebrew_lamed K keycode 46 = l L hebrew_finalkaph L rightdoublequotemark keycode 47 = semicolon colon hebrew_finalpe colon doublelowquotemark keycode 48 = apostrophe quotedbl comma quotedbl U05F4 keycode 49 = grave asciitilde semicolon asciitilde U05F3 keycode 50 = Shift_L ISO_Next_Group Shift_L ISO_Next_Group keycode 51 = backslash bar backslash bar U05BB keycode 52 = z Z hebrew_zain Z keycode 53 = x X hebrew_samech X U05B6 keycode 54 = c C hebrew_bet C U05B1 keycode 55 = v V hebrew_he V keycode 56 = b B hebrew_nun B NoSymbol U05C6 keycode 57 = n N hebrew_mem N keycode 58 = m M hebrew_zade M U05B5 keycode 59 = comma less hebrew_taw greater rightsinglequotemark keycode 60 = period greater hebrew_finalzade less singlelowquotemark keycode 61 = slash question period question division ... etc. etc. ... 

Языковые переменные среды

$ env | grep LANG LANG=en_IL GDM_LANG=en_US.utf8 LANGUAGE=en_IL:en 

Другие заметки

  • Если я создаю чистую учетную запись пользователя, этот пользователь не сталкивается с этой проблемой. Так что это должна быть какая-то пользовательская настройка.
  • Если я копирую текст на иврите, я могу вставить его в приложения, которые не используют иврит, и он отображается нормально.
  • Я сохранил свою домашнюю папку из предыдущей, не Devuan, установки Linux (это был Linux Mint 18.3).
2
Попробуйте это небольшое изменение: `setxkbmap -option grp: switch, grp: alt_shift_toggle, grp_led: прокрутить нас, il`. harrymc 5 лет назад 0
@harrymc: 1. Это не работает. 2. Похоже, это добавляет, а не заменяет параметры xkb (проверяется с помощью `setxkbmap -query`). einpoklum 5 лет назад 0
Я не знаю ваш Linux. Не могли бы вы добавить больше информации о раскладке клавиатуры? Как ты вводишь этих персонажей? Какая у тебя клавиатура? Какие шрифты? harrymc 5 лет назад 0
@harrymc: Физическая раскладка клавиатуры: Добавлено. "Как ты вводишь этих персонажей?" Я нажимаю клавиши на клавиатуре. "Какие шрифты?" Все они, это не имеет значения. einpoklum 5 лет назад 0
Таким образом, вопрос не в том, чтобы «принимать символы» (они просто копируют и вставляют), а в том, чтобы «принимать нажатия клавиш». Первый шаг - запустите `xev` и выясните, какие ключи / коды клавиш отображаются на иврите (пожалуйста, отредактируйте вопрос). Из списка приложений работают приложения KDE и Gnome, в то время как старые приложения, такие как xterm, не работают. Таким образом, предположение, что эти приложения просто не обрабатывают ключевые слова. Вы пробовали urxvt вместо xterm? dirkt 5 лет назад 0
@dirkt: последняя часть вашего комментария неверна - приложения Gnome не работают. einpoklum 5 лет назад 0
@dirkt: Добавлен вывод `xev`. Кажется, что X хорошо видит ивритские символы ... может быть, это gtk / Gnome? einpoklum 5 лет назад 0

3 ответа на вопрос

1
harrymc

Приведенный ниже ответ не решил проблему автора, но последующее обсуждение, наконец, указало на это.

Мы оба пришли к выводу, что причиной проблемы было некоторое различие между монетным двором и девуаном, которое проявилось, когда плакат скопировал всю его домашнюю папку из одной в другую. Большим намеком был тот факт, что под профилем пользователя root проблема не проявлялась.

Затем автор изучил файлы в своей домашней папке, связанные с клавиатурой, и результат можно найти в его ответе.


Ваша проблема, кажется, такая же, как в пост
Терминал не принимает некоторые напечатанные символы Юникода .

Обходной путь, найденный в этом посте, заключался в изменении .Xmodmapи замене имён ключей их шестнадцатеричными кодами Unicode.

В приведенном выше посте для греческого ifonlyifперсонажа постер заменил строку:

код ключа 58 = m M m M процентов Greek_mu KP_1 KP_1 ifonlyif

по линии:

код клавиши 58 = m M m M процентов Greek_mu KP_1 KP_1 U21D4

Не имея своего окружения, я полагаю, что в вашем примере для hebrew_shinключевого кода 38 следует заменить текст на U05E9 (или что-то подобное).

Если это работает для вас, вам нужно сделать то же самое для всех букв иврита, что, к сожалению, будет довольно болезненным. Если вам повезет, шестнадцатеричный код Unicode может быть уже упомянут в Xmodmap, так что вы можете сделать это с помощью некоторой sedмагии.

Ясно, что мне не нужно вносить изменения, относящиеся к конкретному пользователю, и ничего менять вручную. Мне нужны соответствующие файлы, которые в других дистрибутивах (например, Ubuntu, Mint, Fedora) приводят к тому, что все приложения принимают соответствующие символы. Но +1 за вашу помощь пока. einpoklum 5 лет назад 0
Кроме того, это предложение, похоже, неприменимо, так как `xmodmap -pke | grep shin` дает мне `код ключа 38 = a hebrew_shin A U05B0` уже. einpoklum 5 лет назад 0
Странно: [U05B0] (https://codepoints.net/U+05B0?lang=en), похоже, не так. Голень должна быть [U05E9] (http://www.fileformat.info/info/unicode/char/05e9/index.htm). U05B0 является гласным знаком и не имеет собственного отображения. Интересно, в этом ли ваша проблема, что таблица Xmodmap на иврите все испорчено в вашем дистрибутиве для этой раскладки клавиатуры. harrymc 5 лет назад 0
Я постараюсь найти соответствующие файлы (`/ usr / share / xkb`, может быть?) И сравнить их с другими дистрибутивами. einpoklum 5 лет назад 0
Итак, символы / il одинаковы для обоих дистрибутивов. Тем не менее, `U05B0` - это не знак гласного, это модификатор символа shva - который, очевидно, вы должны получить на третьем уровне. Соответствующая строка файла символов: `ключ{[hebrew_shin, A, U05B0]}; // Шва. Теперь вы можете сказать мне: «поменяйте местами« hebrew_shin »на« U05E9 »- но это не« правильный способ »сделать это, потому что в Lubuntu это не так, как в другом месте. Проблема в другом месте, это какая-то проблема интерпретации. einpoklum 5 лет назад 1
Я был разочарован, поэтому я установил Devuan на ВМ и без проблем набрал текст и использовал alt-shift для переключения. Вот [доказательство] (https://i.stack.imgur.com/JGdpe.jpg). Я использовал команду `setxkbmap -option grp: switch, grp: alt_shift_toggle, grp_led: прокрутить нас, il`. Какие бы другие манипуляции вы ни делали, это не помогло и должно быть отменено. harrymc 5 лет назад 0
Примечание: я использовал Devuan Ascii. harrymc 5 лет назад 0
1. Вы использовали терминал. У меня не было проблем с набором текста в терминалах. 2. Я использовал мою домашнюю папку из предыдущего дистрибутива (Linux Mint 18.3). Не могу отменить это - если я не знаю, что нужно отменить. Но я могу подтвердить, что с профилем пользователя root проблема не проявляется. einpoklum 5 лет назад 0
Я думаю, что мы можем заключить, что причина в некоторой разнице между Mint и Devuan, которая проявилась, когда вы скопировали свою домашнюю папку. Может быть, это какой-то файл, связанный с xmodmap в вашей домашней папке. harrymc 5 лет назад 0
Некоторые возможности: `~ / .Xmodmap`,` ~ / .xinitrc`, `~ / .config / autostart / xmodmap.desktop`,` ~ / .bashrc` или `/ etc / bash.bashrc`. Следующее может помочь в отладке: `sudo cat / var / log / syslog | grep -B 5 -A 5 xmodmap`. harrymc 5 лет назад 0
Ничего из этого, но ты вдохновил меня найти решение. Смотрите мой новый ответ. einpoklum 5 лет назад 0
1
einpoklum

Вам необходимо удалить / очистить файл ~ / .xinputrc.

Вдохновленный некоторыми догадками, предложенными @harrymc, я нашел виновника: мой ~/.xinputrcфайл, созданный в моем предыдущем выпуске (Linux Mint 18.3). Это говорит:

# im-config(8) generated on Wed, 25 Jan 2017 22:44:55 +0100 run_im xim # im-config signature: 21f3e409b30c3de81e8302273ccb3d5c - 

im-configМеханизм

метод ввода в X Window System с графическим интерфейсом GTK или диалоговым окном консоли.

который объясняет, почему только (более простые) приложения GTK, кажется, затронуты. Я совсем не знаком с бизнесом метода ввода, но - если я удалю этот файл или закомментирую run_imопцию - все приложения теперь, кажется, принимают ивритские символы, которые я набираю.

0
dirkt

Частичный ответ:

Если вы сравните aи שвы увидите

XLookupString gives 1 bytes: (61) "a" 

против

XLookupString gives 0 bytes: 

И это проблема, потому что, глядя на справочную страницу, XLookupString обрабатывает только Latin-1, поэтому приложения, использующие XLookupString для преобразования нажатий клавиш в символы, получат пустой результат, в результате чего ваши «ивритские символы не будут регистрироваться, пока пунктуация Знаки делают.

И, видимо, некоторые другие приложения, например, KDE, обходят это или используют другой метод.

Я не знаю, как это исправить. Вам нужно будет использовать приложения, которые понимают Unicode / UTF-8, а также правильно переводят полученные ключевые символы. Исправление исходного кода неработающих приложений - вариант, но если бы это было легко, я уверен, что кто-то уже сделал бы это ... так что я бы предположил, что есть некоторые ошибки.

Альтернативы XLookupStringэтой работе с UTF-8 ( Xutf8LookupString ) существуют.

Но это работает с другими дистрибутивами ... и я _am_ использую приложения, которые понимают Unicode. einpoklum 5 лет назад 0
Когда я пытаюсь `xev` на Lubuntu 18.04, он говорит, что` XLookupString дает 2 байта: (d7 a9) "ש" `. einpoklum 5 лет назад 0
Интересно. Похоже, что есть две реализации: одна, которая следует за страницей руководства и говорит, что она должна делать только latin-1, другая, которая игнорирует это и в любом случае выдает utf-8. Это означает, что виновником являются либо разные библиотеки X, либо разные файлы xkbd, которые заставляют XLookupString работать по-разному. Поэтому следующим шагом должен стать просмотр исходного кода XLookupString, используемого Devuan. dirkt 5 лет назад 1
Может быть, это просто с неправильными флагами или что-то? einpoklum 5 лет назад 0
Без понятия. Система сборки X является (или была, когда я в последний раз смотрел на нее) довольно сложной. Я собирал пакеты из исходного кода как для Lubuntu, так и для Devuan, и внимательно смотрел, что произойдет, если это будет моей проблемой, но это может легко занять довольно много времени. dirkt 5 лет назад 0