ЭФ>> 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> неизвестно, для какой именно задачи/сценария потребовалось вводить "ё без точек"
Известно. Я уже выше писал, но могу ещё раз.
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
Здравствуйте, Эйнсток Файр, Вы писали:
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# не может в уникод да?
