Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>План такой:
ЭФ>1) я читаю кодепоинты из UTF-8
ЭФ>2) пишу склеиватель, который управляется внешним конфигом
Зачем конфиг?
ЭФ>3) склеиватель склеивает кодепоинты в TextElements (которые string)
ЭФ>4) делаю "перекодировщик", который управляется внешним конфигом
ЭФ>задача перекодировщика — преобразовывать TextElements в один или несколько символов внутренней кодировки
Зачем?
ЭФ> ffi — это пусть будет один TextElement, но три символа внутренней кодировки.
То есть у вас N байт UTF-8 превращаются одновременно в 1 TextElement, которому соответствует M символов внутренней кодировки?
ЭФ>5) внутри работаю с символами внутренней кодировки фиксированной битности,
ЭФ> при этом отслеживаю из связь с исходными TextElements.
Как именно вы отслеживаете эту связь? Вот у вас лежит массив символов "внутренней кодировки". Три подряд из них соответствуют вот этому ffi, который один и тот же текстовый элемент.
Как именно устроено вот это соответствие?
ЭФ>Если обработка разбивает лигатуру,
ЭФ> то провожу соответствующие операции с TextElement — создаю две штуки
ЭФ>6) при необходимости рисовать пользуюсь TextElements,
ЭФ>обработки делаю во внутренней кодировке
По-прежнему непонятно, что за обработки вы собираетесь делать.
Понимаете, если, к примеру, у вас собственно текст — это сплошной массив "символов" вашей внутренней кодировки, и пользователь, скажем, удаляет первый из них, то что происходит?
Если я правильно понимаю вашу идею, то вам надо
1. Перевыделить массив, сделав его на 1 элемент короче. То есть если у нас там — мегабайт символов, то вы "быренько" копируете весь мегабайт за вычетом первого байта на новое место.
2. Определить, в какой TextElement показывал ваш первый символ. Допустим, это была та самая первая f из лигатуры "ffi". Кстати, в UTF-16 (System.String) это ровно 1 символ: 0xFB03
3. Выполнить переразбиение лигатуры — теперь у вас первый и второй символы должны перестать ссылаться на оригинальный элемент 0xFB03, а должны начать ссылаться на 'f' и 'i', соответственно.
4. Перерисовать весь текст — с учётом того, что у вас сменились позиции всех графем.

ЭФ>Хорошо. Мой случай — должны обрабатываться (игнорироваться) три вида русских ударений.
Ну, как бы и прекрасно. Проблема-то в чём? Чем вас не устраивает стандартный подход в виде деревьев строк/слов/символов?

S>> Так что для отображения слова на арабском вам придётся "собрать" его целиком перед отдачей в рендерер.
ЭФ>Я не планирую поддерживать письмо справа-налево, письмо по столбцам сверху-вниз, и снизу вверх (в реальности существовали все четыре варианта).
Да пёс с ним с направлением. Речь о том, что в арабском письме (и при применении различных "рукописных" шрифтов) отдельно стоящая буква пишется совсем не так, как в составе слова.

ЭФ>Это не мои проблемы, а железа. Мои проблемы — логическая корректность. В конце концов, существуют графические акселераторы, пусть мучаются.
Это очень наивный подход. Вы переваливаете проблемы не на мифические акселераторы, а на пользователей. Которые не захотят пользоваться тормозным продуктом.
Я бы ещё понял, если бы ваш подход как-то упрощал проектирование и кодирование такого редактора — так ведь нет; вы изобретаете себе искусственное усложнение кода, которое ещё и оборачивается плохой асимптотикой в быстродействии. Вы как хотите, а смысл сего от меня ускользает.