Кроме того, даже если обозначить, что переворачивается юникод-строка, она может быть:
— в ненормализованной форме (с лигатурами, встроенными диакритиками, отдельными кодами для форм написания оконечных/начальных букв, и всё что угодно)
— в канонической декомпозиции
— в канонической композиции
— в совместимой декомпозиции
— в совместимой композиции
Понятия «строки» в юникоде нет.
Юникод «строка» — это последовательность code-point'ов.
Их свойства типа модификаторов или обозначения направления — это уже семантика символов, на уровне сбалансированности скобок.
«обращение» такой строки не имеет смысла (интерпретации в виде человекопонятного текста).
Если пытаться «обращать» в контексе человекопонимаемого текста, то есть варианты обращения:
— последовательности «графемных кластеров», определённых в стандарте юникода
— написания элементов слов (с учётом особенностй начертания начальных/конечных букв)
— написания элементов слогов (в слого-ориентированных писменностях)
— произношения (с учётом всей фонологии языка)
А вы смело обозначили, что тут существует всего две проблемы, половина из которых решается библиотечными вызовами.
А варианты написания арабского — это, по идее, задача рендеринга шрифтов, а не представления в строке. Там же где кернинг и антиалиасинг.
Также, как и греческая сигма.
Разные формы имеют собственные кодировки (у арабского — в отдельном диапазоне), но это должно нивелироваться нормализацией.
Есть ещё кластеры в деванагари, представляющие сочетания согласных. Но у них нет даже отдельных представлений в юникоде.
Тоесть тут чистейшей воды задача рендеринга.
Я правда не понял, что с деванагари буквой ssa (из примера в документе)
Кроме хангыля, немного похожая ситуация в тибетском и всяких тайских-кхмерских (элементы слога пишутся сильно нелинейно),
В этих случаях графемный кластер определяется, как базовый символ + расширяющие символы.
А для хангыля — цепочка символов, образующая «слог» и есть графемный кластер.
Но таки да, в любом случае, в условиях задачи надо указывать «обращение порядка графемных кластеров»
А в юникоде вообще есть какое-нибудь (универсальное) понятие, обозначающее атомарные элементы текста, к последовательности которых можно было бы применить термин «обращение»?
Error: Key <HYPR> added to map for multiple modifiers
Using none, ignoring Mod4.
Error: Key <SUPR> added to map for multiple modifiers
Using none, ignoring Mod4.
Думаю, тут стоит упомянуть, что в gnome-3 переделывают работу с клавиатурой, и в gnome-3.8 переключение раскладки штатным методом, или ещё при каких-то переключениях окон, все кастомизации сносятся нахрен.
А «штатным» методом не получится настроить переключение по капс или перемапить Win/Menu.
info.2gis.ru/distributive/shell/last/linux/
info.2gis.ru/distributive/novosibirsk/last/linux/
С помощью которых можно обновлять виндовую версию на линуксовом файл-сервере.
(что-либо более линукс-дружественное вместо msi)
C параметром -label name на кнопках рисуются их названия (формата
<LSGT>
)Соответствие названий кодам хранятся в файле /usr/share/X11/xkb/keycodes/evdev
(ну или то, что подключено через xkb_keycodes )
И таки всё равно, чтобы принять решеине — переключать или не переключать, над знать текущую раскладку.
— в ненормализованной форме (с лигатурами, встроенными диакритиками, отдельными кодами для форм написания оконечных/начальных букв, и всё что угодно)
— в канонической декомпозиции
— в канонической композиции
— в совместимой декомпозиции
— в совместимой композиции
Понятия «строки» в юникоде нет.
Юникод «строка» — это последовательность code-point'ов.
Их свойства типа модификаторов или обозначения направления — это уже семантика символов, на уровне сбалансированности скобок.
«обращение» такой строки не имеет смысла (интерпретации в виде человекопонятного текста).
Если пытаться «обращать» в контексе человекопонимаемого текста, то есть варианты обращения:
— последовательности «графемных кластеров», определённых в стандарте юникода
— написания элементов слов (с учётом особенностй начертания начальных/конечных букв)
— написания элементов слогов (в слого-ориентированных писменностях)
— произношения (с учётом всей фонологии языка)
А вы смело обозначили, что тут существует всего две проблемы, половина из которых решается библиотечными вызовами.
www.unicode.org/reports/tr29/tr29-23.html
А варианты написания арабского — это, по идее, задача рендеринга шрифтов, а не представления в строке. Там же где кернинг и антиалиасинг.
Также, как и греческая сигма.
Разные формы имеют собственные кодировки (у арабского — в отдельном диапазоне), но это должно нивелироваться нормализацией.
Есть ещё кластеры в деванагари, представляющие сочетания согласных. Но у них нет даже отдельных представлений в юникоде.
Тоесть тут чистейшей воды задача рендеринга.
Я правда не понял, что с деванагари буквой ssa (из примера в документе)
Кроме хангыля, немного похожая ситуация в тибетском и всяких тайских-кхмерских (элементы слога пишутся сильно нелинейно),
В этих случаях графемный кластер определяется, как базовый символ + расширяющие символы.
А для хангыля — цепочка символов, образующая «слог» и есть графемный кластер.
Но таки да, в любом случае, в условиях задачи надо указывать «обращение порядка графемных кластеров»
Типа буква + модифицирующие символы.
Но при этом выкидывает ошибку:
Хотя статус завершения 0
clear Mod4
"pc(pc105) ничтоже сумняшеся суёт в Mod4 и Hyper_L и Super_L прикрученные к псевдо-кнопкам
<SUPR> и <HYPR>
Это инклюдится и переписать
modifier_map Mod4 { Super_L, Super_R }
не помогает.Лечится
Но при этом старый добрый xmodmap пишет
А «штатным» методом не получится настроить переключение по капс или перемапить Win/Menu.
Лечится выпиливанием файла /usr/lib/gnome-settings-daemon-3.0/libkeyboard.so
При этом индикатор раскладки не работает, зато работают кастомизации.
Возможно, это касается только кастомизаций через xmodmap, а через xkbcomp всё будет работать.
Думаю, в России, в деревнях Алтая или в глубинах Чукотки и с русским не всё хорошо.