Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Для того, чтобы: ЭФ>1) пользоваться тупыми массивами, в которых индекс буквы совпадает с X-координатой на экране ЭФ>2) использовать меньше памяти.
Первый пункт неосуществим в принципе, из-за комбинирующихся символов в unicode. Вот это, с точки зрения пользователя, 1 буква (попробуйте, к примеру, выделить и скопировать её фрагмент)
-----
Q̹̣̩̭̰̰̹̄ͬ̿͋̃
-----
Но её представление в Unicode состоит из 13 code points.
Как вы собираетесь разместить её в в "тупом массиве"? Сделаете ячейку массива длиной в 26 байт?
Точно так же внутри устроены современные эмоджи: берём базовый смайлик и накладываем произвольное количество комбинаторов.
Кроме того, X-координата на экране выражена в пикселах, что при использовании немоноширинного шрифта приводит к невозможности отображения X в индекс в массиве даже если ограничиться кодами из подмножества Latin1.
Поэтому можно этот пункт выкинуть из рассмотрения и сосредоточиться на втором.
ЭФ>Так-то бы мне и Rune в массиве подошли бы
Повторюсь: смотря для каких целей. Вот чтобы обработать такие строки или эмоджи, вам руны никак не помогут.
ЭФ>Если текст только из цифр, русских и английских букв и некоторых знаков пунктуации, ЭФ>то при использовании внутренней кодировки вполне может хватить одного байта на символ.
Вы сейчас пересказываете краткое содержание сериала "интернационализация в IT", третий сезон, вторая серия "Изобретение UTF-8"
ЭФ>(даже если там будет пара-тройка этих уникальных Grapheme Cluster, которые тоже скодируются в два-три конкретных значения байта).
Что такое "внутренняя кодировка"? ЭФ>Теоретически это может увеличить производительность кода.
Пишу вам в третий раз за последнюю неделю одну и ту же мысль: определитесь с задачей.
Вы всё время думаете об инструментах, и не успеваете задуматься о поводах их применения.
Вот например
1. когда мы двигаем курсор кнопками вправо/влево, что это означает? двигаем на весь grapheme cluster? Или на 1 code point?
1.1. Нужно ли при этом декомпозировать лигатуры, всегда композировать возможные лигатуры, или оставлять как пользователь вставил?
2. Разрешаем ли мы удалять фрагменты кластера?
— да, но только последний модификатор/часть лигатуры
— да, но не даём убрать standalone символ если справа от него есть комбинаторы
— нет, только весь кластер целиком
3. нужно ли нам поддерживать перемещение курсора по словам?
3.1. Что будет считаться границей слова?
4. Какие у нас требования по максимальной длине 1 строки?
5. Какие у нас требования по максимальному количеству строк в тексте?
6. Как быть с размерами шрифтов — важна ли нам возможность пропорционально мастштабировать текст, или пойдёт скачкообразное изменение длин строк?
7. Насколько далеко мы готовы зайти в поддержке всяких экзотических областей unicode? Каким образом будем решать проблему несуществования шрифта, который покрывает все 149+K code points?
примерно так.
Структура данных в памяти для хранения текста будет сильно зависеть от ответов на все эти вопросы.
Но заранее скажу, что массивом рун (или чего бы то ни было) вы не обойдётесь примерно ни в каком случае.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Начнём с того, что юникод 8.0 охватывает более 120 000 символов из более 129 письменностей.
log(2, 120 000) = 16.872674880271
это значит, что все символы в два байта не влезают.
Старые строки в C# насквозь кривые (потому что там два байта на символ) и
не поддерживают модные смайлики и японские символы (а это важно для поколения анимешников!).
Наличие смайликов суперкритично для вставки такого текстового редактора в различные мессенжеры.
. Допустим, что он последний раз программировал на C# в 2005-м году.
Он знает классы String, Encoding и StringBuilder.
А на собеседовании его завалят. Смайлики! Он не в состоянии обработать смайлики в тексте! 👩🔬
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>На stackoverflow сказали что это очень объёмный вопрос, не подходящий для формата их сайта ЭФ>https://stackoverflow.com/questions/18730691/how-to-make-a-custom-text-editor ЭФ>Значит это отличная тема, для того, чтобы обсудить её на форуме!
ЭФ>Начнём с того, что юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. ЭФ>log(2, 120 000) = 16.872674880271 ЭФ>это значит, что все символы в два байта не влезают.
Непонятно, почему вы решили начать обсуждение текстового редактора с юникода.
ЭФ>В текущей редакции 15.0.0, https://www.unicode.org/versions/Unicode15.0.0/ ЭФ>опубликованной 2022-09-13, содержится 149186 символов (то есть ещё больше).
Ну, как бы вы никакой америки тут не открыли. Да, юникод — большой. И что? Вы не в курсе того, как код-поинты укладываются в байты при помощи разных кодировок?
ЭФ>Старые строки в C# насквозь кривые (потому что там два байта на символ) и ЭФ>не поддерживают модные смайлики и японские символы (а это важно для поколения анимешников!).
Ага, то есть не в курсе. Рекомендую разобраться с понятием "кодировка", и с тем, какие кодировки поддерживает дотнет.
ЭФ>Наличие смайликов суперкритично для вставки такого текстового редактора в различные мессенжеры.
Вот это — то, с чего надо было начинать. То есть — набор функциональных и нефункциональных требований.
Редактор для исходного кода; редактор для художественной книги; редактор для научных статей; редактор текстов для мессенджеров — это совершенно разные ниши, с малопересекающимися требованиями.
ЭФ>Вы говорите, что программист на C# легко найдёт работу
. Допустим, что он последний раз программировал на C# в 2005-м году. ЭФ>Он знает классы String, Encoding и StringBuilder. ЭФ>А на собеседовании его завалят. Смайлики! Он не в состоянии обработать смайлики в тексте! 👩🔬
Это вас вообще куда-то не туда повело. Какая разница, кого и где завалят? Почему вас так волнует наличие смайликов на собеседованиях? Почему вы решили, что "он" не в состоянии обработать смайлики?
Каша. В голове — каша.
1. Разбираемся, для какой целевой аудитории и для каких задач мы пишем редактор.
2. Разбираемся, как будет устроена информационная архитектура редактора.
3. Разбираемся, какие отдельные действия будет выполнять пользователь, с какой относительной и абсолютной частотой.
4. Разбираемся, как будет устроена архитектура самого редактора.
5. Разбираемся, как реализовать каждый элемент архитектуры.
Смайлики тут появляются дважды — как нефункциональное требование в п.1, и как подробность реализации в п.5.
Всё. Действуйте по плану, при затруднениях пишите вопросы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>На stackoverflow сказали что это очень объёмный вопрос, не подходящий для формата их сайта ЭФ>Значит это отличная тема, для того, чтобы обсудить её на форуме!
Но ты ничего не обсуждаешь! Ты просто вбросил какую-то галиматью про смайлики! Ты вообще в курсе что такое программирование?? Судя по посту, это какой-то "гуманитарный" высер чела, который сам не знает, чего хочет и что именно у него является проблемой.
ЭФ>Вы говорите, что программист на C# легко найдёт работу
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Начнём с того, что юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. ЭФ>log(2, 120 000) = 16.872674880271 ЭФ>это значит, что все символы в два байта не влезают.
Поэтому в UTF16 один символ может быть закодирован одним или двумя code unit.
ЭФ>В текущей редакции 15.0.0, https://www.unicode.org/versions/Unicode15.0.0/ ЭФ>опубликованной 2022-09-13, содержится 149186 символов (то есть ещё больше).
ЭФ>Старые строки в C# насквозь кривые (потому что там два байта на символ) и ЭФ>не поддерживают модные смайлики и японские символы (а это важно для поколения анимешников!). ЭФ>Наличие смайликов суперкритично для вставки такого текстового редактора в различные мессенжеры.
Строки в C# хранятся в UTF-16
ЭФ>Вы говорите, что программист на C# легко найдёт работу
. Допустим, что он последний раз программировал на C# в 2005-м году. ЭФ>Он знает классы String, Encoding и StringBuilder. ЭФ>А на собеседовании его завалят. Смайлики! Он не в состоянии обработать смайлики в тексте! 👩🔬
Внезапно в состоянии.
Если дистрибутив не поддерживает C# 11:
$ csc -langversion:? | grep "(default)"
9.0 (default)
То застрелиться самому, или искать мейнтейнеров (чтобы застрелить их)?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Начнём с того, что юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. ЭФ>log(2, 120 000) = 16.872674880271 ЭФ>это значит, что все символы в два байта не влезают.
Не надо путать символ и глиф. Например, лигатуры или те же эмодзи — символов несколько, а внешне глиф — один (и при навигации по тексту курсор должен проскакивать все эти символы за один раз как единое целое).
Ещё один аспект, про который надо помнить — поддержка со стороны ОС. Например, у эмодзи есть модификаторы: гендерный, расовый и т.д. И если у нас есть эмодзи "китаянка делает facepalm", то на старых версиях ОС оно может нарисовать вместо одного "правильного" несколько разных глифов: "дефолтный фейспалм", далее глиф "венерино зеркало", а прочие модификаторы вообще проигнорировать или нарисовать на каждый из них глиф-квадратик (default placeholder). Касается не только винды, но и мобильных осей (к слову, Apple обычно быстрее всех начинает поддержку новых эмодзи)
S> руны нужны для представления символа из нескольких char
Дело не в том. Мне просто нужен был тип, который точно соответствует Unicode Codepoint.
И я такой тип нашел. А в день создания топика я о таком типе слыхом не слыхивал.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>how-to-make-a-custom-text-editor ЭФ>Начнём с того, что юникод 8.0 ...
ЭФ, ну как, написал редактор?
Такое ощущение, что ты готовишься к интервью, а не к написанию редактора. В таком случае, становиться "гуру юникода" вообще нет смысла — предполагаю, что всё, что написал тебе Синклер, не знают и 1% погромиздов (включая меня). И так же на интервью мало кто из ВОПРОШАЮЩИХ будет лезть в это юникодное болото (это реально полный мрак).
Хочешь потренировать мозг — напиши тупой редактор с UTF32 под капотом, безо всяких эмодзи, code points и прочего — тупо "редактор 32-битных текстов"
По-моему, как и с HTML, юникодный стандарт свернул куда-то очень не туда. В гейропах Эпплю ПРИНУЖДАЮТ использовать USB-C вместо Lightning, но при этом никого не принуждают бросать свои извращенства (вроде письма справа-налево) и писать "как все". Вот по-моему глобализация и должна как-то сдвигать этот маразм в сторону унификации. Не говоря о том, что в общем случае большинству из 8,000,000,000 людей как-то похрен, уместятся ли шумерские письмена в юникод или нет. Надо остановиться на UTF16 (с фиксированным 2-байтовым символом), всунув туда все алфавиты по приоритету количества людей, знающих данный язык. Кто не уместился — пусть сами изобретают себе кодировки (если у них в племени вообще есть компьютеры! ). А всякие лигатуры и "комбинации" — к чёрту, без них все прекрасно жили (напомню, даже ASCII каких-то 20 лет назад всем хватало).
Чем больше мудаки из unicode усложняют и извращают стандарт (эмоджи?? серьёзно?!), тем меньше вероятность написания качественного софта. Мы слишком много прыгаем вокруг "второстепенных людей/языков", приводя адекватный мир в ступор.
S> неизвестно, для какой именно задачи/сценария потребовалось вводить "ё без точек"
Известно. Я уже выше писал, но могу ещё раз.
1) Русский язык записывается с помощью кириллического алфавита.
2) буква "ё" равноправная и ничем не ущербная.
3) некоторые люди сто лет назад не могли "ё", но могли "е".
4) они издохли давно уже все, и чихать я на них хотел.
5) лично я желаю видеть букву "ё", если она должна писаться в своём месте по смыслу.
6) но иногда приходится копировать текст из интернета, куда он попал из старых книжек, и там может быть "е".
7) можно ли обойтись без "ё"? Нет, для меня это категорически неприемлемо.
8) надо уметь отображать книжку/цитату как она выглядела в лохматом году,
но быть твёрдо уверенным, что где надо располагаются буквы "ё", хотя они и выглядят как "е".
9) причём древние тексты могут быть перемешаны с современными, а разделить их метаданными никак нельзя.
Если бы это был HTML, то можно было бы приделать стиль, а потом куски с таким стилем деёфицировать джаваскриптом. Но HTML-я нет, есть plain-text.
Право писать на родном языке даровано гражданину конституцией.
Каждый кто против конституции и предлагает без буквы "ё" обойтись,
должен преследоваться по УК по статье о подготовке свержения строя.
В редких случаях вставки цитат из древних текстов
можно скрыть точки при выводе для аутентичности, не более.
Сценарий:
автор текста вводит строки, слова и буквы, а так же вставляет в него фрагменты других текстов, скопированных из интернета. Проставляет буквы "ё" где считает нужным, реализуя своё конституционное право. Сохраняет аутентичность оригинального вида цитат. Буквы "ё" навсегда остаются доступны для автоматизированной обработки, например поиска, как в авторском тексте, так и в процитированном. Совместимость желательно иметь с максимальным количеством утилит (grep, leafpad, firefox).
Инженерное решение тут — донести задачу до комитета по стандартизации Unicode и включить механизм стирания акцентов в Unicode 16.0.0 (или другой, следующий актуальный).
Либо пойти по пути Китая, у них есть своя редакция Unicode, с другим порядком codepoint-ов — GB-18030.
support for the mandatory subset is officially required for all software products sold in the PRC
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Как написать редактор текстов на C#?
двусвязный список для символов ?
помню в универе за вечер в качестве лабы — написал пейнт под дос (не полноценный конечно, как был под windows — но фигуры можно было рисовать), а также текстовый редактор (тоже под дос) но там я схалтурил и реализовал алгоритм в лоб, поэтому на текстах чутка минимального большего размера — всё жутко тормозило .. (но я естественно при сдаче — об этом скромно умолчал)
I've been using the following code to translate unicode parts that are taken from a text file in a format of string array ["1F3F3", "FE0F", "200D", "1F308"]. The mentioned unicode parts are a sample of 🏳️🌈 emoji and are taken from unicode.org resource(#1553 on the page).
public static void PrintEmoji(params string[] unicodeParts)
{
var unicodeBuilder = new StringBuilder();
foreach (var unicodePart in unicodeParts)
{
unicodeBuilder.Append(char.ConvertFromUtf32(Convert.ToInt32(unicodePart,16)));
}
if(unicodeBuilder.ToString() is var unicodeResult && !string.IsNullOrWhiteSpace(unicodeResult))
Console.WriteLine(unicodeResult);
}
То есть использовать Encoding.UTF32. Не?
и солнце б утром не вставало, когда бы не было меня
Хочу сказать, что не вижу в интернете простого примера
как развернуть строку "👩🔬: 🙈, 🙉, 🙊.".
S> Ну для уменьшения аллокаций есть например Utf8String type
Да, уже упомянул эту багу в своём втором сообщении топика.
Проблема в том, что этого класса ещё нет, и компилятора C# 11 у меня нет.
This repo contains designs proposed by the CLR team but not yet committed for inclusion in either the C# language or the standard .NET Framework. The types included here (e.g. Utf8Span) may never appear in the official standard.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Начнём с того, что юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. ЭФ>log(2, 120 000) = 16.872674880271 ЭФ>это значит, что все символы в два байта не влезают.
Это верно
ЭФ>Старые строки в C# насквозь кривые (потому что там два байта на символ) и ЭФ>не поддерживают модные смайлики и японские символы (а это важно для поколения анимешников!).
За смайлики не знаю, но с японскими символами работаю около 12и лет через C# строки и никаких проблем пока не обнаружил. Все за редким исключением находятся в UCS. ЭФ>Наличие смайликов суперкритично для вставки такого текстового редактора в различные мессенжеры.
Вот тут не очень понимаю, причем тут C# и его способ представления символов? Чем он мешает работе редактора? Для редактора нужно уметь отображать символы на графическом устройстве, брать текст на входе, отдавать на выходе. Отображением занимается шрифт, там фактически лежат инструкции по отрисовке глифов, их размеры, отступы, они не привязаны к C# представлению строк. Вход-выход текста в редактор можно вполне реализовать через юникод.
ЭФ>Вы говорите, что программист на C# легко найдёт работу
. Допустим, что он последний раз программировал на C# в 2005-м году. ЭФ>Он знает классы String, Encoding и StringBuilder. ЭФ>А на собеседовании его завалят. Смайлики! Он не в состоянии обработать смайлики в тексте! 👩🔬
Что подразумевается под словом "обработать"?
Если нужно отобразить смайлик на устройстве и человек когда-то слышал об юникоде и в состоянии открыть хотя бы википедию, то для отображения смайлика ему не потребуется String, Encoding и StringBuilder. Нужно лишь понять, как в шрифте найти глиф, соотвествующий закодированному символу. Для этого есть API в соотвествующих библиотеках по работе со шрифтами.
Создание редактора, поддерживающего нюансы юникода — задача не формата собеседования. Но посмотреть, ход мыслей кандидата при получении такого задания — было бы прикольно.
Кроме того, не надо мне тыкать глифами. Глиф — это только часть графемы:
A glyph is an image, usually stored in a font (which is a collection of glyphs), used to represent graphemes or parts thereof.
A grapheme is a sequence of one or more code points that are displayed as a single, graphical unit that a reader recognizes as a single element of the writing system.
character is an individual unit of text composed of one or more graphemes.
Unicode provides rules for the interpretation of juxtaposed graphemes as individual characters.
Unicode rules allow some juxtaposed graphemes to be interpreted as other graphemes
that already have their own code points (precomposed forms).
Следующая у меня проблема — это как рисовать.
Firefox символы показывает, а вот текстовый редактор — нет, причём я перебрал все шрифты, не подходит ни один.
То есть, в системе есть как минимум один Unicode-дный шрифт (им и рисует firefox), но к программам это почему-то не относится.
S> причем тут C# и его способ представления символов? Чем он мешает работе редактора?
Редактор редактирует модель текста. Бывает два типа:
— текстовые редакторы
— текстовые процессоры
В текстовых редакторах модель текста попроще. Текст состоит из строк, строки состоят из символов.
В текстовых процессорах модель посложнее. Есть "Стили", они применяются к фрагментам текста. Есть структура текста (заголовки, абзацы).
Если рассматривать Grapheme Clusters — то это глубоко внутренняя проблема кодировки Unicode.
Простой текстовый редактор работает с одной Grapheme Cluster как с одним знакоместом (прямоугольником),
поэтому можно вообще посчитать, сколько каких Grapheme Cluster-ов в файле в штуках
и перекодировать всё во внутреннюю кодировку с одинаковой битностью, с которой потом и работать.
А для того, чтобы не писать отдельный код для 8, 16, 32 битов на символ — использовать классы-шаблоны и типизировать их типами-структурами такого размера.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>АДНАКА, я поискал такой код на github (чтобы там было ReadOnlySpan<Rune>) и не нашел. ЭФ>В интернете тоже не густо...
Повторно вам поясню: надо начинать с задачи, а не с инструмента. Зачем вы всё делаете задом наперёд?
Что именно вы хотите сделать с уникодом в .Net?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если рассматривать Grapheme Clusters — то это глубоко внутренняя проблема кодировки Unicode.
Похоже, проблема не в Unicode и не в кодировках.
ЭФ>Простой текстовый редактор работает с одной Grapheme Cluster как с одним знакоместом (прямоугольником),
Ну, так и замечательно. Проблема-то в чём? Что именно вы хотите сделать? ЭФ>поэтому можно вообще посчитать, сколько каких Grapheme Cluster-ов в файле в штуках ЭФ>и перекодировать всё во внутреннюю кодировку с одинаковой битностью, с которой потом и работать.
Зачем вы хотите перекодировать всё во внутреннюю кодировку?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
S>> То есть использовать Encoding.UTF32. Не?
ЭФ>Оказывается, начиная с Core, есть такой класс Rune в System.Text (а в mono его вроде нет): ЭФ>https://learn.microsoft.com/en-us/dotnet/api/system.text.rune?view=net-6.0
ЭФ>а чтобы эти руны в строки склеивать есть ReadOnlySpan<T>
Ну руны нужны для представления символа из нескольких char
По той же ссылке
int CountLetters(string s)
{
int letterCount = 0;
foreach (Rune rune in s.EnumerateRunes())
{
if (Rune.IsLetter(rune))
{ letterCount++; }
}
return letterCount;
}
Ниже приведен эквивалентный код, который работает со ReadOnlySpan<char>следующим кодом:
static int CountLetters(ReadOnlySpan<char> span)
{
int letterCount = 0;
foreach (Rune rune in span.EnumerateRunes())
{
if (Rune.IsLetter(rune))
{ letterCount++; }
}
return letterCount;
}
Приведенный выше код правильно подсчитывает буквы Osage:
CountLettersInString("𐓏𐓘𐓻𐓘𐓻𐓟 𐒻𐓟")
// Returns 8
ЭФ>АДНАКА, я поискал такой код на github (чтобы там было ReadOnlySpan<Rune>) и не нашел. ЭФ>В интернете тоже не густо...
и солнце б утром не вставало, когда бы не было меня
S> Зачем вы хотите перекодировать всё во внутреннюю кодировку?
Для того, чтобы:
1) пользоваться тупыми массивами, в которых индекс буквы совпадает с X-координатой на экране
2) использовать меньше памяти.
Так-то бы мне и Rune в массиве подошли бы (Но это неточно, так как Grapheme Cluster туда не влезет), но 4 байта это 4 байта (вроде как это расточительно).
Если текст только из цифр, русских и английских букв и некоторых знаков пунктуации,
то при использовании внутренней кодировки вполне может хватить одного байта на символ
(даже если там будет пара-тройка этих уникальных Grapheme Cluster, которые тоже скодируются в два-три конкретных значения байта).
Теоретически это может увеличить производительность кода.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Дело не в том. Мне просто нужен был тип, который точно соответствует Unicode Codepoint.
Скорее всего вам нужно не это.
The number of Rune instances in a string might not match the number of user-perceivable characters shown when displaying the string.
Since Rune instances represent Unicode scalar values, components that follow the Unicode text segmentation guidelines can use Rune as a building block for counting display characters.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
посчитать, сколько каких Grapheme Cluster-ов в файле в штуках
и перекодировать всё во внутреннюю кодировку с одинаковой битностью, с которой потом и работать.
А для того, чтобы не писать отдельный код для 8, 16, 32 битов на символ — использовать классы-шаблоны и типизировать их типами-структурами такого размера.
Это значит, что будет массив из пар, например, строк и байтов (или дерево с хештаблицами, чтобы в строках искать быстрее, пока неважно)
Строка будет содержать в себе встреченный Grapheme Cluster, байт будет содержать порядковый номер (т.е. внутренний код).
В тот момент, когда количество символов станет превышать 256 или 65536 (что вряд ли), будет происходить перекодирование всего текста (с копированием по памяти) во внутреннюю кодировку с удвоенным числом битов, но по-прежнему одинаковым на все Grapheme Cluster-ы.
Поэтому неверно, что эта кодировка похожа на UTF-8. Моя будет оставаться фиксированной длины, а UTF-8 это кодировка переменной длины.
На те вопросы, на которые нет ответов, отвечаю:
1) я не собираюсь "разбирать" длинные Grapheme Cluster-ы (они же TextElement в .NET)
редактор не будет уметь их редактировать, только копипастить из буфера целиком (в буфер они будут попадать из браузера) или стирать насмерть.
2) про границы слов я пока не думал вообще, но такая информация скорее всего получается из CharUnicodeInfo
Если не получится, поищу на гитхабе библиотеку, которая реализует
"Unicode UAX #29 §4.1 default word boundary specification"
3) про размер памяти под текст тоже не думал и не буду, у меня на одной из машине 256GB RAM, буду хранить текстовый буфер в памяти на ней.
4) про шрифты я ещё ничего не знаю, буду читать позже. Мне достаточно повторить то, что делает Firefox (потому что я именно из него копирую).
А могли бы, наверное, и сделать, если бы вместо "this" писать ключевое слово "type", чтобы применялись эти методы и свойства не к объекту класса, а к самому классу.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Это значит, что будет массив из пар, например, строк и байтов (или дерево с хештаблицами, чтобы в строках искать быстрее, пока неважно)
Это значит, что у вас даже для маленьких текстов будет +1 уровень косвенности. То есть вместо просто символа A вы храните у себя сам символ А, и ещё массив ссылок на строки, у которых вначале идёт длина, и уже потом — символы UCS4, из которых собственно и состоит текст. Ну либо вы оставляете null для тех символов, которые означают сами себя, тогда немножко экономите по памяти, но производительность всё равно будет так себе.
Весь выигрыш от возможности сделать line[i] вы тут же и потеряете. К тому же не сможете пользоваться векторными инструкциями для ускорения операций.
На первый взгляд кажется, что держать вместо этого дерево строк, в котором каждый лист будет в какой-то одной кодировке, будет гораздо эффективнее.
Чисто Latin1-текст будет ровно одним фрагментом однобайтовых символов.
ЭФ>В тот момент, когда количество символов станет превышать 256 или 65536 (что вряд ли), будет происходить перекодирование всего текста (с копированием по памяти) во внутреннюю кодировку с удвоенным числом битов, но по-прежнему одинаковым на все Grapheme Cluster-ы.
С точки зрения пользователя это будет выглядеть как пауза в работе, и про вас будут писать на хабре "о боже, 2023 год, а у меня ввод текста лагает".
Дерево позволяет все ситуации обработать за O(1). ЭФ>1) я не собираюсь "разбирать" длинные Grapheme Cluster-ы (они же TextElement в .NET)
ЭФ>редактор не будет уметь их редактировать, только копипастить из буфера целиком (в буфер они будут попадать из браузера) или стирать насмерть.
Тогда придётся их разбирать. Ровно потому, что у вас одна "буква" (то, что стирается целиком при нажатии backspace или del) занимает неизвестное количество "символов", в какой кодировке бы они ни были. Опять же, в дереве вы можете держать такой кластер отдельным листом, и забесплатно иметь возможность быстро перемещаться между "буквами".
ЭФ>2) про границы слов я пока не думал вообще, но такая информация скорее всего получается из CharUnicodeInfo ЭФ>Если не получится, поищу на гитхабе библиотеку, которая реализует ЭФ>"Unicode UAX #29 §4.1 default word boundary specification"
Библиотека — это хорошо. Но вопрос в том, как вы будете эти границы искать в момент нажатия Ctrl-влево или Ctrl-вправо. Линейным поиском по символам внутренней кодировки? С учётом того, что для восстановления полноценного UCS4 вам нужно прыгать по двум ссылкам для каждого символа?
Опять же имеет смысл использовать для этого древовидную структуру, в которой всё это делается за O(1).
ЭФ>3) про размер памяти под текст тоже не думал и не буду, у меня на одной из машине 256GB RAM, буду хранить текстовый буфер в памяти на ней.
Если вас не беспокоит размер памяти, тогда нафига задуряться с перекодировками? Сразу храните всё в UCS4.
ЭФ>4) про шрифты я ещё ничего не знаю, буду читать позже. Мне достаточно повторить то, что делает Firefox (потому что я именно из него копирую).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Не тут же, а только при сохранении и рисовании.
S>С точки зрения пользователя это будет выглядеть как пауза в работе, и про вас будут писать на хабре "о боже, 2023 год, а у меня ввод текста лагает".
Можно это делать заранее, кроме того это один раз.
ЭФ>>редактор не будет уметь их редактировать, только копипастить из буфера целиком (в буфер они будут попадать из браузера) или стирать насмерть. S> придётся их разбирать
Только при считывании.
S> прыгать по двум ссылкам
Никаких двух ссылок не будет. Внутренний код символа (байт) — это индекс в массиве.
Уровень перенаправления конечно будет один лишний, но он не ссылка, и им не обязательно пользоваться всегда.
S> Если вас не беспокоит размер памяти, тогда нафига задуряться с перекодировками? Сразу храните всё в UCS4.
Составные Grapheme Cluster не влезут в 4 байта целиком, особенно когда там 2 и более кодепоинтов.
А если будет перекодирование для обеспечения одинаковой битности всем символам,
то нет разницы, в 4, 2 или 1 байт перекодировать (в зависимости от количества разных символов в конкретном тексте).
Зато у меня убыстрятся все другие обработки, если они будут. Например парсинг не будет динамически разбираться
сколько там кодепоинтов начиная с каждой позиции. А будет работать по своим таблицам, построенным в соответствии с внутренней кодировкой.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Не тут же, а только при сохранении и рисовании.
При всех операциях. Собственно, всё, чем занимается редактор — это рисование.
1. Рисование в ответ на изменение view (скроллинг, ресайз, перемещение курсора)
2. Рисование в ответ на изменение model
Ну, и собственно сами изменения модели.
ЭФ>Можно это делать заранее, кроме того это один раз.
"Заранее" как раз и означает, что вы всегда держите весь текст в одной кодировке. Например, в UCS4.
ЭФ>Никаких двух ссылок не будет. Внутренний код символа (байт) — это индекс в массиве.
Смотрите. Массив — это ссылка, pArrayStart.
Обращение к элементу массива — это один дереференс, *(pArrayStart + charCode).
По этому адресу лежит ссылка на ваш graphemeCluster.
То есть чтобы узнать длину этого кластера, нужно обратиться вот так:
ЭФ>Уровень перенаправления конечно будет один лишний, но он не ссылка, и им не обязательно пользоваться всегда.
Нет никаких способов перенаправления, кроме ссылок. Вы можете обозвать эту ссылку числом, но внутри CPU всё равно будет выполнять те же сдвиги, сложения, и дереференс.
ЭФ>Составные Grapheme Cluster не влезут в 4 байта целиком, особенно когда там 2 и более кодепоинтов.
Совершенно верно, не влезут. ЭФ>А если будет перекодирование для обеспечения одинаковой битности всем символам, ЭФ>то нет разницы, в 4, 2 или 1 байт перекодировать (в зависимости от количества разных символов в конкретном тексте).
Количество разных символов — штука динамическая. А вам ещё и придётся как-то обрабатывать ситуации, когда пользователь вводит, скажем, суррогатные пары по одному символу при помощи Alt-ввода.
Ну по факту вы всё равно придёте к дереву. Не имеет смысла представлять мегабайтный текст как один массив длиной в миллион — вставка в середину обходится слишком дорого.
Просто сейчас у вас получается плоское дерево, где узлы хранят ссылки на "кластеры", а когда вы оптимизируете это для операций редактирования, то сплошной массив превратится в похожую на rope структуру.
Плюс к этому вы обвесите эту структуру данными по расположению символов на канвасе, для пересчёта "символьной" позиции в координатную и обратно.
ЭФ>Зато у меня убыстрятся все другие обработки, если они будут. Например парсинг не будет динамически разбираться
Тут главное — заранее понять, какие именно у вас будут обработки.
ЭФ>сколько там кодепоинтов начиная с каждой позиции. А будет работать по своим таблицам, построенным в соответствии с внутренней кодировкой.
На этом вы ничего не выиграете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
S>> чтобы узнать длину этого кластера,
ЭФ>Мне не нужно этого делать в общем случае, только при операциях ввода-вывода.
S>>Тут главное — заранее понять, какие именно у вас будут обработки.
ЭФ>Любые, фиксированный размер символа ускорит любые обработки.
Ну дык и храни все в UTF-32 и не будет проблем. Я так понимаю, что Rune как раз 4 байта (Int32)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мне не нужно этого делать в общем случае, только при операциях ввода-вывода.
Вам это будет нужно сделать при каждом выводе на экран.
ЭФ>Любые, фиксированный размер символа ускорит любые обработки.
(вздыхает) нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Любые, фиксированный размер символа ускорит любые обработки.
Вопрос со звёздочкой: планируете ли вы использовать шрифты с лигатурами? Скажем, насколько важна для вас поддержка арабской письменности?
Чтобы она работала корректно, вам нужно передавать в рендерер шрифта их не по одному, а сразу всем блоком.
Так что для отображения слова на арабском вам придётся "собрать" его целиком перед отдачей в рендерер. У вас банальный repaint, когда поверх вашего окошка двигают какое-то другое, будет тормозить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
ЭФ>>Мне не нужно этого делать в общем случае, только при операциях ввода-вывода. S>Вам это будет нужно сделать при каждом выводе на экран.
Собственно, есть такой редактор, Scintilla. И там таки реализовали эту "гениальную" идею, jagged массив с символами. Правда символ у них был поначалу 1 байт. А для юникода они потом заюзали UTF-8. В результате их API превратился в какое то фантастическое говно. С тех пор так и живут уже много лет.
ЭФ>>Любые, фиксированный размер символа ускорит любые обработки. S>Вопрос со звёздочкой: планируете ли вы использовать шрифты с лигатурами? Скажем, насколько важна для вас поддержка арабской письменности?
План такой:
1) я читаю кодепоинты из UTF-8
2) пишу склеиватель, который управляется внешним конфигом
3) склеиватель склеивает кодепоинты в TextElements (которые string)
4) делаю "перекодировщик", который управляется внешним конфигом
задача перекодировщика — преобразовывать TextElements в один или несколько символов внутренней кодировки
ffi — это пусть будет один TextElement, но три символа внутренней кодировки.
5) внутри работаю с символами внутренней кодировки фиксированной битности,
при этом отслеживаю из связь с исходными TextElements. Если обработка разбивает лигатуру,
то провожу соответствующие операции с TextElement — создаю две штуки
6) при необходимости рисовать пользуюсь TextElements,
обработки делаю во внутренней кодировке
S> Чтобы она работала корректно, вам нужно передавать в рендерер шрифта их не по одному, а сразу всем блоком.
Хорошо. Мой случай — должны обрабатываться (игнорироваться) три вида русских ударений.
S> Так что для отображения слова на арабском вам придётся "собрать" его целиком перед отдачей в рендерер.
Я не планирую поддерживать письмо справа-налево, письмо по столбцам сверху-вниз, и снизу вверх (в реальности существовали все четыре варианта).
S> У вас банальный repaint, когда поверх вашего окошка двигают какое-то другое, будет тормозить.
Это не мои проблемы, а железа. Мои проблемы — логическая корректность. В конце концов, существуют графические акселераторы, пусть мучаются.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>План такой: ЭФ>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>> Так что для отображения слова на арабском вам придётся "собрать" его целиком перед отдачей в рендерер. ЭФ>Я не планирую поддерживать письмо справа-налево, письмо по столбцам сверху-вниз, и снизу вверх (в реальности существовали все четыре варианта).
Да пёс с ним с направлением. Речь о том, что в арабском письме (и при применении различных "рукописных" шрифтов) отдельно стоящая буква пишется совсем не так, как в составе слова.
ЭФ>Это не мои проблемы, а железа. Мои проблемы — логическая корректность. В конце концов, существуют графические акселераторы, пусть мучаются.
Это очень наивный подход. Вы переваливаете проблемы не на мифические акселераторы, а на пользователей. Которые не захотят пользоваться тормозным продуктом.
Я бы ещё понял, если бы ваш подход как-то упрощал проектирование и кодирование такого редактора — так ведь нет; вы изобретаете себе искусственное усложнение кода, которое ещё и оборачивается плохой асимптотикой в быстродействии. Вы как хотите, а смысл сего от меня ускользает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ЭФ>> 1) я читаю кодепоинты из UTF-8 ЭФ>> 2) пишу склеиватель, который управляется внешним конфигом ЭФ>> 3) склеиватель склеивает кодепоинты в TextElements (которые string) S> Зачем конфиг?
Эти TextElements — это то (последовательности CodePoint-ов),
что шрифт должен удачно отрендерить как единый объект.
Можно было бы назвать его даже RenderingElement.
Если в коде файла три буквы 'f', 'f', 'i' в виде трёх кодепоинтов,
то сами они никак не склеятся в один кодепоинт с кодом 0xFB03.
И это не фича UTF-16, а
прямо в Unicode есть такой codepoint — https://unicodemap.org/details/0xFB03/index.html
Вы предлагаете полагаться на систему (и АПИ) рендеринга,
чтобы о таких штуках знала она, но не знал я.
Мне мешает так поступить:
1) незнание того, как этот рендеринг в точности работает
и как на него влиять (для этого, вероятно, надо редактировать определение шрифта);
2) незнание АПИ.
Если же я делаю свой конфиг, то в нём я дублирую эту информацию понятным мне способом.
Мне кажется, что это будет быстрее и проще,
чем изучать все хитросплетения существующих реализаций.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Эти TextElements — это то (последовательности CodePoint-ов), ЭФ>что шрифт должен удачно отрендерить как единый объект. ЭФ>Можно было бы назвать его даже RenderingElement.
ЭФ>Если в коде файла три буквы 'f', 'f', 'i' в виде трёх кодепоинтов, ЭФ>то сами они никак не склеятся в один кодепоинт с кодом 0xFB03.
Сами — не склеятся. Но у вас же нет цели самостоятельно нормализовывать все композиции? Всегда можно выполнить декомпозицию и определить границы TextElement по классу unicode chars. ЭФ>И это не фича UTF-16, а ЭФ>прямо в Unicode есть такой codepoint — https://unicodemap.org/details/0xFB03/index.html
Ну всё верно. Я же вас спрашивал с самого начала — хотите ли вы декомпозировать лигатуры, или вас устроит удаление всей лигатуры целиком?
ЭФ>Вы предлагаете полагаться на систему (и АПИ) рендеринга, ЭФ>чтобы о таких штуках знала она, но не знал я.
Нет, я предлагаю не это. Я предлагаю для внутреннего представления текста использовать дерево. В самом низу этого дерева пусть лежат последовательности символов в такой кодировке, которая удобна для передачи в платформенные функции отображения — например, UTF-16. А узлами дерева будут собственно TextElement, Word, Line. Детали по-прежнему зависят от того, что вы хотите написать. Пока что мы ничего не знаем, кроме того, что вы хотите уметь работать с ударениями (для которых, вообще говоря, достаточно выучить ровно один combining diacritic character) в кириллице и смайликами.
ЭФ>Мне мешает так поступить: ЭФ>1) незнание того, как этот рендеринг в точности работает ЭФ>и как на него влиять (для этого, вероятно, надо редактировать определение шрифта); ЭФ>2) незнание АПИ.
Без знания АПИ и понимания того, как работает рендеринг, вы всё равно ничего не напишете. ЭФ>Если же я делаю свой конфиг, то в нём я дублирую эту информацию понятным мне способом. ЭФ>Мне кажется, что это будет быстрее и проще, ЭФ>чем изучать все хитросплетения существующих реализаций.
Нет, это будет медленнее и сложнее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S> Детали по-прежнему зависят от того, что вы хотите написать. Пока что мы ничего не знаем, кроме того, что вы хотите уметь работать с ударениями (для которых, вообще говоря, достаточно выучить ровно один combining diacritic character) в кириллице и смайликами.
Меня в первую очередь волнует обработка текста.
Мне кажется, что если обработка текста будет сделана корректно,
то потом поверх можно будет без проблем сделать и редактирование.
Грубо говоря, я хочу две(три) сборки/assembly:
1) библиотеку/фреймворк для работы с юникодом;
2) код, который будет текст обрабатывать на самом деле;
3) редактор (опционально).
Поэтому я не вполне понимаю, почему вы спрашиваете про декомпозицию лигатур.
S> Я же вас спрашивал с самого начала — хотите ли вы декомпозировать лигатуры, или вас устроит удаление всей лигатуры целиком?
Меня не волнует редактирование как таковое.
Поэтому я не понимаю, почему вы задаёте этот вопрос, причём несколько раз подряд.
ЭФ>>Вы предлагаете полагаться на систему (и АПИ) рендеринга, ЭФ>>чтобы о таких штуках знала она, но не знал я. S> Я предлагаю для внутреннего представления текста использовать дерево. В самом низу этого дерева пусть лежат последовательности символов в такой кодировке, которая удобна для передачи в платформенные функции отображения — например, UTF-16. А узлами дерева будут собственно TextElement, Word, Line.
Поиск — это обработка.
Потому что если у вас на нижнем уровне лигатура ffi, то буква i внутри неё не будет найдена при поиске, потому что в вашей логической модели её нет как отдельного объекта.
А если заранее разобъёте на отдельные Codepoint, то вот другой контрпример про смайлики:
if we want to find an ear of rice 🌾 U+1F33E then it'll match 👨🌾 unexpectedly because that farmer emoji is encoded as U+1F468 U+200D U+1F33E
Если в первом случае для обработки разбивать надо, то во втором как раз не надо.
Ваш подход бажный, некорректно обрабатывает текст и вы не прошли собеседование про смайлики.
Вместо использования АПИ с функцией TextElement (которая реализована непонятно как, и, вероятно, опирается на реализацию базы юникодных символов в glibc) я предлагаю закодировать правила из стандарта (14 штук) https://unicode.org/reports/tr29/#Extend
прямо на сишарпе в виде ДКА, как они там предлагают. Возможно библиотека ICU.NET https://github.com/sillsdev/icu-dotnet
это делает, но в любом случае она обёртка над C++-кодом. И это плохо, потому что существуют pure C# операционки, куда это не влезет.
Но чисто сишарповая реализация неважна, это был так, вбоквел к обсуждению.
S> у вас же нет цели самостоятельно нормализовывать все композиции?
Если я правильно понимаю, то нормализация — это преобразование исходного потока байтов, то есть уже операция по его редактированию. Если есть такая операция, то должна быть обратная операция — денормализация (для движка Undo/Redo). Я не могу не делать нормализацию самостоятельно, если .Net Framework не предоставляет обратной операции. Это, конечно, в том случае, если я правильно понимаю слово "нормализация", как объединение букв f, f, i в одну лигатуру ffi всегда. Я сомневаюсь, что .Net framework делает такое объединение при нормализации.
Normalization Form KC does not attempt to map character sequences to compatibility composites. For example, a compatibility composition of “office” does not produce “o\uFB03ce”, even though “\uFB03” is a character that is the compatibility equivalent of the sequence of three characters “ffi”.
В моём представлении это происходит при рендеринге (а если не происходит, то рендеринг выполняется некорректно, лигатура не отрисовывается).
S> в арабском письме (и при применении различных "рукописных" шрифтов) отдельно стоящая буква пишется совсем не так, как в составе слова.
Ну, такая же проблема, как у лигатуры ffi, или нет?
Главное, что в результате разбора у меня будут не только TextElement, но и их связь с исходными позициями в потоках Codepoint и byte.
S> Как именно вы отслеживаете эту связь? Вот у вас лежит массив символов "внутренней кодировки". Три подряд из них соответствуют вот этому ffi, который один и тот же текстовый элемент. Как именно устроено вот это соответствие?
В виде .Net объекта. У меня "лежат" (будут лежать):
1) массив байтов
2) массив кодепоинтов
3) массив TextElement
4) массив моих "внутренних" символов
4-3) массив связок типа "4-3" с количеством объектов как в 4
3-2) массив связок типа "3-2" с количеством объектов как в 3
2-1) не хранится, потому что может быть вычислен алгоритмически на лету.
При создании символов массива 4 я могу провести мою унификацию — преобразовать ударения в свойства этих символов.
То есть, если TextElement имели значения "а" и "а́", то им будут соответствовать два объекта "а" и "а" класса "4", но с разными значениями свойства "ModernRussianStress" (false и true).
Тип char не даст мне хранить при себе свойства, потому что он слишком простой для этого.
S> вы хотите уметь работать с ударениями (для которых, вообще говоря, достаточно выучить ровно один combining diacritic character) в кириллице
Кириллицей так же записываются церковные книги. А в староцерковном языке три типа ударений — "оксия", "вария", "камора". Вы просто не любите русских и стремитесь уничтожить наше духовное наследие.
Ещё эта фигня с необязательностью точек над ё. Нужен будет специальный код, который правильно угадывает букву "ё", но помечает её признаком "WithoutPointsOverIt".
S> будет медленнее и сложнее.
Да мне пофиг, даже если каждый объект в памяти будет минимум 32 байта. Память железная, а я с мозгами из мяса.
ЭФ>Меня в первую очередь волнует обработка текста.
Обработка обработке рознь.
ЭФ>Поэтому я не вполне понимаю, почему вы спрашиваете про декомпозицию лигатур.
Потому, что я опираюсь на те обрывочные сведения о функциональности, которые вы предоставили.
ЭФ>Меня не волнует редактирование как таковое.
Из названия топика это сложно вывести.
ЭФ>Поиск — это обработка.
ЭФ>Потому что если у вас на нижнем уровне лигатура ffi, то буква i внутри неё не будет найдена при поиске, потому что в вашей логической модели её нет как отдельного объекта.
ЭФ>А если заранее разобъёте на отдельные Codepoint, то вот другой контрпример про смайлики: ЭФ>
if we want to find an ear of rice 🌾 U+1F33E then it'll match 👨🌾 unexpectedly because that farmer emoji is encoded as U+1F468 U+200D U+1F33E
начинать надо с набора требований. ЭФ>Если в первом случае для обработки разбивать надо, то во втором как раз не надо. ЭФ>Ваш подход бажный, некорректно обрабатывает текст и вы не прошли собеседование про смайлики.
ЭФ>это делает, но в любом случае она обёртка над C++-кодом. И это плохо, потому что существуют pure C# операционки, куда это не влезет. ЭФ>Но чисто сишарповая реализация неважна, это был так, вбоквел к обсуждению.
Ну, не нужно так не нужно. Зачем тогда вы фокусируетесь на этом? S>> у вас же нет цели самостоятельно нормализовывать все композиции?
ЭФ>Если я правильно понимаю, то нормализация — это преобразование исходного потока байтов, то есть уже операция по его редактированию. Если есть такая операция, то должна быть обратная операция — денормализация (для движка Undo/Redo). Я не могу не делать нормализацию самостоятельно, если .Net Framework не предоставляет обратной операции. Это, конечно, в том случае, если я правильно понимаю слово "нормализация", как объединение букв f, f, i в одну лигатуру ffi всегда. Я сомневаюсь, что .Net framework делает такое объединение при нормализации.
Зачем сомневаться? Есть же спецификация, в которой написано, что именно делает нормализация.
ЭФ>В тексте стандарта написано: ЭФ>
Normalization Form KC does not attempt to map character sequences to compatibility composites. For example, a compatibility composition of “office” does not produce “o\uFB03ce”, even though “\uFB03” is a character that is the compatibility equivalent of the sequence of three characters “ffi”.
ЭФ> В моём представлении это происходит при рендеринге (а если не происходит, то рендеринг выполняется некорректно, лигатура не отрисовывается).
При рендеринге "это" происходит при соблюдении двух условий:
1. Используемый шрифт умеет лигатуры (то есть специальные начертания для последовательностей символов)
2. В функции вывода текста вы скармливаете не отдельные символы, а готовые последовательности.
То есть какие-то шрифты могут выводить строку "ffi" как лигатуру, но большинство — как три обычных буквы. Даже если для символа \uFB03 в этом шрифте есть глиф. Эта штука ортогональна уникоду.
Примеры применения можете посмотреть в статье на хабре про шрифты для программистов.
S>> в арабском письме (и при применении различных "рукописных" шрифтов) отдельно стоящая буква пишется совсем не так, как в составе слова.
ЭФ>Ну, такая же проблема, как у лигатуры ffi, или нет?
Нет, ортогональная. Посмотрите на статью выше — чтобы шрифт FiraCode вывел != как "перечёркнутое равно", вы должны подать в функцию TextOut именно строку с "!=", а не сделать два отдельных вызова TextOut("!"), TextOut("=").
ЭФ>Главное, что в результате разбора у меня будут не только TextElement, но и их связь с исходными позициями в потоках Codepoint и byte.
S>> Как именно вы отслеживаете эту связь? Вот у вас лежит массив символов "внутренней кодировки". Три подряд из них соответствуют вот этому ffi, который один и тот же текстовый элемент. Как именно устроено вот это соответствие?
ЭФ>При создании символов массива 4 я могу провести мою унификацию — преобразовать ударения в свойства этих символов. ЭФ>То есть, если TextElement имели значения "а" и "а́", то им будут соответствовать два объекта "а" и "а" класса "4", но с разными значениями свойства "ModernRussianStress" (false и true).
Да, это правильная идея. В том смысле, что модель текста фундаментально зависит от сценариев использования. Если редактор должен давать размечать текст жирным и курсивным начертанием, то потребуется соответствующая модель, которая применяет стили к тексту. Если вам важно отслеживать ударение как свойство текста, то можно сделать такой модификатор. Само по себе это свойство не нужно.
ЭФ>Тип char не даст мне хранить при себе свойства, потому что он слишком простой для этого.
Необходимые свойства выводятся из сценариев использования; сценарии — из требований.
ЭФ>Кириллицей так же записываются церковные книги. А в староцерковном языке три типа ударений — "оксия", "вария", "камора".
Повторюсь: невозможно спроектировать решение, не поставив задачу. Вы впервые упоминаете про необходимость работать с текстами церковных книг. Есть такая необходимость — ок, будем поддерживать три вида комбинирующих символов. Нет необходимости — не будем. ЭФ>Вы просто не любите русских и стремитесь уничтожить наше духовное наследие.
А вот хамить не надо.
ЭФ>Ещё эта фигня с необязательностью точек над ё. Нужен будет специальный код, который правильно угадывает букву "ё", но помечает её признаком "WithoutPointsOverIt".
Повторюсь: требования к коду выводятся из сценариев. Зачем вам код, угадывающий букву ё? Возможно, для нужного вам сценария можно обойтись и без угадывания?
Потому что я затрудняюсь себе представить компактное решение, способное правильно расставить точки над ё во тексте "Осел так и осел, словно сделавшись меньше. Совершенный им поступок теперь не казался совершенным."
ЭФ>Да мне пофиг, даже если каждый объект в памяти будет минимум 32 байта. Память железная, а я с мозгами из мяса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ЭФ>> Вы просто не любите русских и стремитесь уничтожить наше духовное наследие. S> А вот хамить не надо.
Живя в России
Вы уважаете требования мусульман,
чтобы их арабские буквы из Корана корректно рендерились в составе слова и вне его,
а про православные книги, по-Вашему требования не было.
Ну и кто Вы после этого?
S> Вы впервые упоминаете про необходимость работать с текстами церковных книг. Есть такая необходимость — ок, будем поддерживать три вида комбинирующих символов. Нет необходимости — не будем.
Почему у меня такое требование возникло, а у Вас такого требования не было? При том, что я атеист...
S> Зачем вам код, угадывающий букву ё?
Затем, что если правила языка есть, то они должны быть автоматизированы.
Очевидное же требование?
Греф отчитывается, что у него огромные нейросети на самом мощном суперкомпьютере Европы,
и что его специалисты построили самую полную модель русского языка,
а мы стесняемся какую-то "ё" детектировать...
В конце концов, пусть редактор размечает, где неопределённости, если сам определить не может.
И различает уже проверенные и ещё непроверенные места (запоминает принятые решения).
Интересно, есть ли в Unicode такой код, который затирает ранее приписанные умляуты?
То есть:
1) буква "ё" — кодируется в байты как есть;
2) буква "ё", записанная как "е" — это "е" + умляут + CGJ + BACKSPACE,
или, можно даже "е" + CGJ + умляут + ZWJ + BACKSPACE;
3) буква "е", записанная как "е" + какой-нибудь символ уверенности, это определённо именно "е",
можно, например, использовать "е" + CGJ + "неразрывный пробел" + ZWJ + BACKSPACE;
4) буква "е" без ничего — это неразрешённая неопределённость.
BACKSPACE =U+0008, DEL = U+007F (пока не рендерится так, как я хочу ни то, ни другое).
"неразрывный пробел" = U+00A0
Combining Grapheme Joiner (CGJ) = U+034F
Zero Width Joiner (ZWJ) = U+200D , pronounced "zwidge", is a Unicode character that joins two or more other characters together in sequence to create a new emoji
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Живя в России ЭФ>Вы уважаете требования мусульман,
С чего вы взяли? Я вам просто приводил пример того, что посимвольный рендеринг не работает с лигатурными шрифтами. Нужен он вам или нет — зависит от ваших требований.
Если вас устраивает то, что пользователь вашего редактора не получит красивеньких операторов для =>, -->, !===, и прочего, просто выставив ему шрифт Fira Code — да пожалуйста.
Я не могу придумать требования за вас.
ЭФ>чтобы их арабские буквы из Корана корректно рендерились в составе слова и вне его, ЭФ>а про православные книги, по-Вашему требования не было.
Конечно. Покажите мне пост в этом топике, где вы упомянули православные книги. Вы упомянули только одно — что хотите игнорировать три вида русских ударений.
ЭФ>Ну и кто Вы после этого?
Я — product manager с опытом 15 лет.
ЭФ>Почему у меня такое требование возникло, а у Вас такого требования не было? При том, что я атеист...
Потому, что я не пишу редактор. . По-моему, это очевидно. Я могу только самые общие требования к редактору предполагать — например, чтобы он умел корректно отображать текст при помощи выбранного шрифта, и чтобы не тормозил при каждом нажатии на клавишу.
ЭФ>Затем, что если правила языка есть, то они должны быть автоматизированы. ЭФ>Очевидное же требование?
Это — нет. Повторюсь: требования диктуются сценариями пользователей. Вне сценариев функциональных требований не существует.
Каждый раз, когда вы принимаете решения вида "давайте сделаем так", то нужно понимать, для чего.
Например, если вы захотите сделать редактор, который способен помогать пользователю дописывать стихотворные рифмы к строчкам, вам не хватит "правил про букву ё", зато потребуется затащить в редактор много информации о русской фонетике. А если не захотите — не потребуется.
ЭФ>Греф отчитывается, что у него огромные нейросети на самом мощном суперкомпьютере Европы, ЭФ>и что его специалисты построили самую полную модель русского языка, ЭФ>а мы стесняемся какую-то "ё" детектировать...
Ну, Греф много что может не стесняться делать. К вам-то это какое отношение имеет?
ЭФ>В конце концов, пусть редактор размечает, где неопределённости, если сам определить не может.
Зачем? ЭФ>И различает уже проверенные и ещё непроверенные места (запоминает принятые решения).
Зачем? У всего должна быть какая-то цель.
ЭФ>Интересно, есть ли в Unicode такой код, который затирает ранее приписанные умляуты?
Нет.
ЭФ>Что-нибудь типа такого: ЭФ>https://www.compart.com/en/unicode/U+007F ЭФ>(не работает у меня в firefox) ЭФ>или такого: ЭФ>https://www.compart.com/en/unicode/U+2421 ЭФ>(этот именно буковки по диагонали рисует, тоже не годится)
Зачем вам такой символ?
Вы опять ставите решение впереди задачи. У вас совершенно конкретная задача — отобразить "ё без точек". Она решается тупо отображением кириллической буквы "е".
Как оно там у вас внутри устроено — зависит от того, какие ещё требования у вас есть. Хотите, чтобы такая буква находилась в тексте при поиске "обычной" буквы ё, и не находилась в тексте при поиске буквы "е" — будут одни требования, и один набор решений. Не захотите — будет другой набор возможных решений.
ЭФ>То есть: ЭФ>1) буква "ё" — кодируется в байты как есть; ЭФ>2) буква "ё", записанная как "е" — это "е" + умляут + CGJ + BACKSPACE, ЭФ> или, можно даже "е" + CGJ + умляут + ZWJ + BACKSPACE; ЭФ>3) буква "е", записанная как "е" + какой-нибудь символ уверенности, это определённо именно "е", ЭФ> можно, например, использовать "е" + CGJ + "неразрывный пробел" + ZWJ + BACKSPACE; ЭФ>4) буква "е" без ничего — это неразрешённая неопределённость.
Старайтесь чётче отличать требования от их реализации.
ЭФ>В общем, Unicode не готов к русскому языку.
Не, это вы пока не готовы приступить к решению задачи. В основном — потому, что сами не знаете, чего именно вы хотите.
Конечно, не обязательно придерживаться водопадной модели. В пет-проектах можно (и даже нужно) бегать взад-вперёд по шкале от требований к реализации и обратно.
Но нужно помнить о том, что в итоговом продукте, если он приемлемого качества, всё равно прослеживается вот эта вот зависимость между сценариями, фичами, архитектурой/дизайном, и реализацией.
Поэтому при переключениях между уровнями абстракции надо эти зависимости восстанавливать, и без стеснения выбрасывать либо технические решения, которые не удовлетворяют выявленным требованиям, либо требования, несовместимые с получившимся техническим решением.
Ещё очень важно избавиться от иллюзии, что существуют какие-то "объективные и само собой разумеющиеся" требования к произвольной задаче.
Что редактор — вот я пишу "надо реализовать библиотеку для арифметических действий". Думаете, если задать толпе программистов вопрос "как реализовать библиотеку для арифметических действий", то на него будет строго один верный вариант ответа?
Угу. Внезапно, арифметика для целых фиксированного размера, для чисел с плавающей запятой, для целых произвольного размера, для чисел с фиксированной запятой — это совершенно разные арифметики.
И предпочесть одну другой без явно заданных требований невозможно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S> У вас совершенно конкретная задача — отобразить "ё без точек". Она решается тупо отображением кириллической буквы "е".
Вы сузили мою задачу. Моя задача не только в том, чтобы отобразить, но ещё и в том, чтобы сохранить (ну и ввести ещё, но это неважно).
А сохранить "ё без точек" в Unicode нельзя. Сохранится другая буква. Я об этом и написал.
И сценарий использования очевидный и широкораспространённый.
Полно книг вокруг, где используется буква "ё", но написанная без точек.
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Вы сузили мою задачу. Моя задача не только в том, чтобы отобразить, но ещё и в том, чтобы сохранить (ну и ввести ещё, но это неважно). ЭФ>А сохранить "ё без точек" в Unicode нельзя. Сохранится другая буква. Я об этом и написал.
В Unicode ещё много чего нельзя сделать. Не получится сохранить "текст с подчёркиванием", "текст курсивом", или "текст светло-синего цвета".
Нет возможности сохранить, допустим, текст "ПАПА ПРАВ" так, чтобы все буквы, кроме первой, "на самом деле" были строчными, просто отображёнными в виде заглавных (режим All Caps в MS Word).
Нет возможности указать, что ширины пробелов между словами должны быть подобраны так, чтобы стороны все строчки заканчивались ровно на правой границе, при этом в рамках всего блока текста была достигнута как можно более равномерная оптическая плотность.
В основном — потому, что unicode и не предполагал подобных задач. На ранних этапах его пробовали для этого применять — см. например subscripts and superscripts, — но быстро перестали добавлять подобные возможности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S> Не получится сохранить "текст с подчёркиванием", "текст курсивом", или "текст светло-синего цвета"
Это всё мне не требуется, я рассматриваю редактирование условного "простого текста",
в котором из всей метаинформации есть только BOM и разделители строк.
S> unicode и не предполагал подобных задач
Но мне-то прямо сейчас что делать?
S> выбрасывать ... требования, несовместимые с ... техническим решением
Не годится.
Моё предложение такое:
1) определить/создать формат "Unicode + 'е/ё без точек'" поверх Unicode;
2) использовать этот формат, и сказать, что так и надо.
Просто вы не знаете о разнице между текстовыми процессорами и текстовыми редакторами.
Отличие текстового процессора от редактора состоит в том, что в файл добавлены специальные коды, макросы (особые программы), определяющие вид документа.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Но мне-то прямо сейчас что делать?
1. Разбираемся, для какой целевой аудитории и для каких задач мы пишем редактор.
2. Разбираемся, как будет устроена информационная архитектура редактора.
3. Разбираемся, какие отдельные действия будет выполнять пользователь, с какой относительной и абсолютной частотой.
4. Разбираемся, как будет устроена архитектура самого редактора.
5. Разбираемся, как реализовать каждый элемент архитектуры.
S>> выбрасывать ... требования, несовместимые с ... техническим решением
ЭФ>Не годится.
ЭФ>Моё предложение такое: ЭФ>1) определить/создать формат "Unicode + 'е/ё без точек'" поверх Unicode; ЭФ>2) использовать этот формат, и сказать, что так и надо.
Это может оказаться корректным решением. Поскольку постановка задачи так и не выполнена, совершенно невозможно сказать, будет ли оно корректным или нет.
Например, неизвестно, должен ли этот формат быть совместимым со сторонним софтом, и если да, то с каким, и в рамках каких сценариев.
Также неизвестно, для какой именно задачи/сценария потребовалось вводить "ё без точек" и почему без такого введения решительно невозможно обойтись. У любой задачи есть несколько разных решений.
Чтобы между ними выбирать, нужно учитывать большой набор требований. Как правило, эти требования конфликтуют между собой — это и есть признак инженерной задачи. Если нет конфликта требований — то и инженер не нужен: просто делай всё первым способом, и всё
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
S>> посимвольный рендеринг не работает с лигатурными шрифтами. ЭФ>
Лигатуры — это не юникод, это фишка open type font. В редакторах кода они как правило отключены за ненадобностью
Я знаю, что такое лигатуры. Про "как правило" — художественный свист. Редакторов кода без поддержки шрифтовых лигатур — раз, два, и обчёлся.
И, главное, это — нерелевантно вообще. Мой поинт был не в том, что вам нужно срочно заменить шрифт в Gvim на Fira Code, а в том, что вообще лигатурные шрифты бывают в природе. И при разработке "текстового редактора", что бы это ни значило, надо принимать решение — либо осознанно отказываться от поддержки таких шрифтов, либо, наоборот, прилагать усилия по их поддержке.
ЭФ>Просто вы не знаете о разнице между текстовыми процессорами и текстовыми редакторами. ЭФ>
Отличие текстового процессора от редактора состоит в том, что в файл добавлены специальные коды, макросы (особые программы), определяющие вид документа.
Это — чрезмерно упрощённая классификация. И текстовые процессоры бывают очень разными — задачи подготовки текста, стоящие перед секретаршей в офисе, перед математиком, и перед историком-медиевистом, очень разные.
И "текстовый редактор" тоже бывает очень разным — это может быть F4 в Far, Notepad.exe, или редактор из Visual Studio.
Вам нужно усвоить одну простую вещь: решения диктуются требованиями. Никто за вас требования к вашему продукту не будет придумывать и приоритизировать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ЭФ>1) Русский язык записывается с помощью кириллического алфавита. ЭФ>2) буква "ё" равноправная и ничем не ущербная. ЭФ>3) некоторые люди сто лет назад не могли "ё", но могли "е". ЭФ>4) они издохли давно уже все, и чихать я на них хотел. ЭФ>5) лично я желаю видеть букву "ё", если она должна писаться в своём месте по смыслу. ЭФ>6) но иногда приходится копировать текст из интернета, куда он попал из старых книжек, и там может быть "е". ЭФ>7) можно ли обойтись без "ё"? Нет, для меня это категорически неприемлемо. ЭФ>8) надо уметь отображать книжку/цитату как она выглядела в лохматом году, ЭФ> но быть твёрдо уверенным, что где надо располагаются буквы "ё", хотя они и выглядят как "е". ЭФ>9) причём древние тексты могут быть перемешаны с современными, а разделить их метаданными никак нельзя.
Вот это всё — сырой поток сознания. Нельзя так мыслить, как минимум при разработке софта.
ЭФ>Если бы это был HTML, то можно было бы приделать стиль, а потом куски с таким стилем деёфицировать джаваскриптом. Но HTML-я нет, есть plain-text.
Вот это вот требование откуда взялось? Оно объективно важно, или просто из воздуха придумано?
ЭФ>Право писать на родном языке даровано гражданину конституцией.
Опять пошёл поток сознания. Конституция и требования к программному продукту не связаны примерно никак.
ЭФ>Каждый кто против конституции и предлагает без буквы "ё" обойтись, ЭФ>должен преследоваться по УК по статье о подготовке свержения строя.
Это очень интересная тема, и в другой раз я бы с удовольствием обсудил выбор подходящей статьи УК. Но к разработке софта это никакого отношения не имеет; если хотите — можете пойти в форум "политика" и там начать агитировать за внедрение буквы ё без точечек методами уголовного преследования. А здесь лучше оффтопа избегать.
ЭФ>В редких случаях вставки цитат из древних текстов ЭФ>можно скрыть точки при выводе для аутентичности, не более.
Непонятно, зачем что-то скрывать. Честному человеку скрывать нечего.
ЭФ>Сценарий: ЭФ>автор текста вводит строки, слова и буквы, а так же вставляет в него фрагменты других текстов, скопированных из интернета. Проставляет буквы "ё" где считает нужным, реализуя своё конституционное право. Сохраняет аутентичность оригинального вида цитат. ЭФ>Буквы "ё" навсегда остаются доступны для автоматизированной обработки, например поиска, как в авторском тексте, так и в процитированном. Совместимость желательно иметь с максимальным количеством утилит (grep, leafpad, firefox).
В сформулированном виде задача не выглядит реализуемой. Придётся чем-то пожертвовать. Например, "совместимостью" с grep-ом. Точнее — смотря как вы себе представляете эту совместимость.
Вот, допустим, есть у пользователя текст "автор этой идеи — осел", обработанный вашим "редактором". Пользователь "проставил" в этом месте "секретную" букву ё, оставив её для аутентичности без точек.
Теперь он хочет найти этот документ грепом по слову "осёл". Будет ли он хвалить вас за ваше нововведение, когда документ не найдётся?
Что он скажет, убедившись, что по слову "осел" этот текст тоже не находится?
Догадается ли он, что нужно не набирать текст на клавиатуре, а пойти в ваш редактор, набрать там "осёл", скрыть точки, скопировать результат в аргументы команды grep, и искать только так? И даже реализация вот этого вычурного и неудобного пользователю сценария потребует от вас значительных усилий при разработке формата представления и самого редактора.
ЭФ>Инженерное решение тут — донести задачу до комитета по стандартизации Unicode и включить механизм стирания акцентов в Unicode 16.0.0 (или другой, следующий актуальный).
И чем вам это поможет?
Скорее всего, все реально полезные вашим пользователям сценарии покрываются галочкой "Accent insensitive" в настройках поиска в вашем редакторе.
Плюс, быть может, соответствующие контент экстракторы для поисковых машин винды и популярных СУБД. Потому что в реале никому эти "невидимые точки" нахрен не нужны. Если пользователь хочет писать всё через ё — то он просто так и сделает, и не будет переживать о том, что текст утратил аутентичность. Если пользователю важнее сохранить орфографию оригинала — то он поставит е и не будет переживать о том, что какой-то умерший поэт выбрал не ту букву.
Если пользователь захочет найти в тексте слово "всё", то будет искать слово "всё". Если он захочет находить его в обоих формах, независимо от того как оно выглядит (и уж тем более независимо от того, успел ли он заменить е на ё-без-точек), то он будет искать в accent insensitive режиме.
Если пользователю нужно, чтобы поиск строки "fi" находил как "fi", так и fi-лигатуру, а также часть ffi-лигатуры (ксстати, как вы будете подсвечивать найденное, если это 1 code point?), то сделайте, чтобы находил (нормализованное представление вам в помощь). Если нужно, чтобы поиск fi-лигатуры находил только эту лигатуру, но не отдельные последовательности из букв f и i, и не ffi-лигатуру, то сделайте, чтобы он так и делал.
Если нужно и то и другое — то придётся прикрутить режимы поиска, или ещё как-то изощряться для того, чтобы и задачу решить, и чтобы пользователь это решение понял.
ЭФ>Либо пойти по пути Китая, у них есть своя редакция Unicode, с другим порядком codepoint-ов — GB-18030. ЭФ>
support for the mandatory subset is officially required for all software products sold in the PRC
Опять у вас решение доминирует над задачей.
Причём явно надуманное и избыточное решение. Вы же могли просто добавить в Unicode 1 букву — ё-без-точек. А не заставлять все реализации обрабатывать произвольную смесь из базовых символов, джойнеров, и backspace.
Посмотрите на турков — у них есть i-без-точки. Обошлись без стирания.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S> просто добавить в Unicode 1 букву — ё-без-точек.
Нельзя, потому что в русском алфавите 33 буквы, а не 35
(ведь надо добавить две буквы:
1) «'ё'-которая-выглядит-как-'е'»;
2) «'е'-которая-точно-не-'ё'»;
).
S> явно надуманное и избыточное
Это не логика, а эмоции. С таким подходом в программировании нельзя.
Рассуждая по-аналогии ваш подход с "accent insensitive" явно недодуманный и недостаточный.
Я бы точно так же мог сказать, что лично Вам вообще не надо пользоваться кириллическим алфавитом, пользуйтесь латинским, Вам будет достаточно и решит большинство Ваших задач. И никакие Ваши возражения не принимаются, потому что есть миллиард англоговорящих людей которым всего хватает.
S> в реале никому эти "невидимые точки" нахрен не нужны.
Но вы-то за право не писать 'ё' сражаетесь как обезьяна.
Проблема в том, что Unicode выполняет две функции:
1) описание того, как символы рисуются;
2) описание того, что с символами делать.
Надо просто разбить этот стандарт на два.
в качестве первого можно продолжить использовать Unicode
В качестве второго создать новый стандарт, с бо́льшим количеством управляющих кодов.
В юникоде большой перевес разных вариантов использования именно латинского алфавита.
Нет скомбинированных символов, где верхними и нижними индексами являются русские буквы, например.
А потом обязать всё ПО России следовать второму стандарту, как это сделали в Китае.
Если китайский стандарт поддерживается в glibc, то можно было бы добавить и поддержку российского стандарта с "е"-"ё" туда же тоже в glibc. И тогда grep бы начал точнее искать ослов, а firefox правильнее отображать.
Упрятанная минимальная текстовая разметка на уровне национальной кодировки эту сложность скроет. Кто надо — будет знать, кто не знает, просто будет использовать.
Почему бы не использовать HTML в качестве такого второго стандарта. Да потому что он большой и сложный. И мало кто будет учить HTML для того, чтобы просто редактировать тексты. Markdown неспроста появился.
Если просто использовать HTML, то grep тоже не найдёт там слово "осёл", потому что буква 'ё' будет заключена в символы разметки:
ос<span class="looks-as-e">ё</span>л
Значит, надо придумывать специальные соглашения, вроде того, что "выделяться должна вся цитата целиком".
Наличие разметок типа MarkDown и HTML не скрыть, они слишком вылезают и бросаются в глаза.
Чтобы они этого не делали, надо:
1) запретить все редакторы для plaintext не поддерживающие национальный формат разметки текстов;
2) реализовать стандарт во всех программах, которыми пользуются люди.
Кроме редакторов, ещё есть компиляторы всякие и прочие обработчики. И HTML они потреблять как есть не будут. А если разметку засунуть в кодировку, то смогут.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Начнём с того, что юникод 8.0 охватывает более 120 000 символов из более 129 письменностей. ЭФ>log(2, 120 000) = 16.872674880271 ЭФ>это значит, что все символы в два байта не влезают.
ЭФ>В текущей редакции 15.0.0, https://www.unicode.org/versions/Unicode15.0.0/ ЭФ>опубликованной 2022-09-13, содержится 149186 символов (то есть ещё больше).
Че за паника кек
Unicode так-то имеет 32bit призентацию ну где-то 1FFF FFFF символов(щас может и больше) и то что вы привыкли что в винде unicode 16bit то это просто способ кодирования, на деле оно может представить любой символ уникоде, но некоторые могут занять от 3 до 4 байт на символ. в винде и функции есть типа GoNextChar(WCHAR*) и PrevChar которая показывает указатель на следующий/предидуший символ. Если использовать эти функции для перемешений между символами то никаких проблем нет ни с японским ни с эмоджи.
А че C# не может в уникод да?
