Здравствуйте, пффф, Вы писали:

П>Произвольный именно текст, эмоджи идут в жопу, LTR/RTL нужно, вперемешку — скорее да
Ну, тогда, наверное, при выводе надо полагаться на GDI-шные функции, которые позволяют рассчитать положение всех символов; а при редактировании можно делить по базовым/модификаторам.
То есть если у нас курсор стоит вот так: ё|жик и мы нажимаем backspace, то удалять надо всю букву, независимо от того, представлена ли она в предкомбинированном виде, либо в виде "е c умляутом".
Точно так же делаем, если у нас курсор стоит вот так жуль|ё и мы нажимаем del.
Аналогично — выделение, копирование, вырезание и вставка: копируются базовые символы со всеми их модификаторами.
Раз emoji не важны, на ZWJ можно забить. Если нет — то можно его тоже использовать как критерий объединения: x<zwj>y<zwj>z должно выделяться/копироваться/удаляться как единый символ.
С RTL я подробностей не помню. AFAIR, там основное — понять, какое направление у нас главное.
Если мы имеем LTR-текст с редкими вкраплениями RTL фрагментов, то навигация по тексту устроена так, что кнопка -> сдвигает курсор "дальше" от начала строки (в терминах последовательности unicode codepoint). При натыкании на RTL-фрагмент, курсор "прыгает" через фрагмент, и кнопка -> начинает его двигать справа налево (т.к. по-прежнему двигает курсор "дальше" от начала строки в терминах последовательности unicode codepoint).
А если у нас основное направление RTL, то логичнее инвертировать поведение кнопок <- и ->. Ну, потому, что иначе редактирование чисто-RTLного текста выглядит контр-интуитивно.

См. тж. https://habr.com/ru/post/104493/

Здравствуйте, пффф, Вы писали:

П>Привет!

П>Хз в какой форум с такой темой, если что — перенесите куда правильно.

П>Вопрос — как правильно итерироваться по юникодному тексту? По символам я умею, как в UTF-8 (линупсы), так и по виндовому WCHAR* — UTF-16 вроде же?

П>Но ведь это ничего не значит, потому что один глиф (или как правильно сказать?) может состоять из нескольких codepoints, так?
То что ты хочешь называется графемами — https://unicode.org/reports/tr29/


П>В винде, допустим, должны быть какие-то функции на эту тему (кстати, какие?).
Я посмотрел реализацию итератора по графемами в .NET — нет, там все самописное.

П>А как быть в линупсе? Я немного почитал про composition/decomposition, там про какие-то таблицы декомпозиции пишут. Самому с этим возиться неохота. Есть какое-то стандартное API, которое всегда есть или может быть легко установлено?
Нет такого стандартного АПИ, видимо потому что оно никому не нужно.
По факту в шрифтах лигатуры назначаются просто на набор (любое количество) кодпоинтов и не факт что это будет соотноситься со сецификацией юникода.


П>Кстати, некоторые раскладки в винде могут генерить целые пачки символов — лигатуры, например в персидском аж до 4х WCHAR может быть за одно нажатие.
Это и есть графемы.

П>А отображается — как один символ.
Это уже лигатуры.

П>Тут явно больше одного UTF-32 codepoints.
Скорее всего 4


П>Если они могут быть подвергнуты композиции — то почему это не сделано?
Это сделано шлрифтом.

П>А если не могут, то как по ним корректно итерироваться?
Искать готовую библиотеку на твоем языке по работе с графемами или постигать работу со шрифтами.