Сообщение Re[5]: Как написать редактор текстов на C#? от 01.11.2022 16:04
Изменено 01.11.2022 17:17 Sinclair
Re[5]: Как написать редактор текстов на C#?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Для того, чтобы:
ЭФ>1) пользоваться тупыми массивами, в которых индекс буквы совпадает с X-координатой на экране
ЭФ>2) использовать меньше памяти.
Первый пункт неосуществим в принципе, из-за комбинирующихся символов в unicode. Вот это, с точки зрения пользователя, 1 буква (попробуйте, к примеру, выделить и скопировать её фрагмент)
Как вы собираетесь разместить её в в "тупом массиве"? Сделаете ячейку массива длиной в 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?
примерно так.
Структура данных в памяти для хранения текста будет сильно зависеть от ответов на все эти вопросы.
Но заранее скажу, что массивом рун (или чего бы то ни было) вы не обойдётесь примерно ни в каком случае.
ЭФ>Для того, чтобы:
ЭФ>1) пользоваться тупыми массивами, в которых индекс буквы совпадает с X-координатой на экране
ЭФ>2) использовать меньше памяти.
Первый пункт неосуществим в принципе, из-за комбинирующихся символов в unicode. Вот это, с точки зрения пользователя, 1 буква (попробуйте, к примеру, выделить и скопировать её фрагмент)
Но её представление в Unicode состоит из 13 code points.-----
Q̹̣̩̭̰̰̹̄ͬ̿͋̃
-----
Как вы собираетесь разместить её в в "тупом массиве"? Сделаете ячейку массива длиной в 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?
примерно так.
Структура данных в памяти для хранения текста будет сильно зависеть от ответов на все эти вопросы.
Но заранее скажу, что массивом рун (или чего бы то ни было) вы не обойдётесь примерно ни в каком случае.
Re[5]: Как написать редактор текстов на C#?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Для того, чтобы:
ЭФ>1) пользоваться тупыми массивами, в которых индекс буквы совпадает с X-координатой на экране
ЭФ>2) использовать меньше памяти.
Первый пункт неосуществим в принципе, из-за комбинирующихся символов в unicode. Вот это, с точки зрения пользователя, 1 буква (попробуйте, к примеру, выделить и скопировать её фрагмент)
Как вы собираетесь разместить её в в "тупом массиве"? Сделаете ячейку массива длиной в 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?
примерно так.
Структура данных в памяти для хранения текста будет сильно зависеть от ответов на все эти вопросы.
Но заранее скажу, что массивом рун (или чего бы то ни было) вы не обойдётесь примерно ни в каком случае.
ЭФ>Для того, чтобы:
ЭФ>1) пользоваться тупыми массивами, в которых индекс буквы совпадает с X-координатой на экране
ЭФ>2) использовать меньше памяти.
Первый пункт неосуществим в принципе, из-за комбинирующихся символов в unicode. Вот это, с точки зрения пользователя, 1 буква (попробуйте, к примеру, выделить и скопировать её фрагмент)
Но её представление в Unicode состоит из 13 code points.-----
Q̹̣̩̭̰̰̹̄ͬ̿͋̃
-----
Как вы собираетесь разместить её в в "тупом массиве"? Сделаете ячейку массива длиной в 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?
примерно так.
Структура данных в памяти для хранения текста будет сильно зависеть от ответов на все эти вопросы.
Но заранее скажу, что массивом рун (или чего бы то ни было) вы не обойдётесь примерно ни в каком случае.