HarfBuzz 11.5.0

А при чем тут диван

Мои фанаты знают, что Devuan на большинстве моих скриншотов.
Я ваш кумир!

И для чего же?

Уточнение: UCS-2(utf-16) хороший правильный уникод

ucs-2 слишком мал (математика, скажем, в него не помещается), а utf-16 такой же переменный, как и utf-8, так что не лучше него, а хуже.

Мои фанаты знают, что Devuan на большинстве моих скриншотов.

Так это ему ТВОЯ «маргинальность» на лоре не нравится?!

Ясно, понятно

Тогда utf-16 в топку. Оставляем в списке хороших кодировок только ucs-2(и другие 16-bit fixed length если они существуют)

Был неправ. Variable lenght utf-16 мусор

Длина представления кодпойнтов не имеет значения, так как обращение к Юникод-строке по индексу лишено всякого смысла.

По-простому harfbuzz извлекает из шрифта нужное начертание глифа в соответсвии со свойствами опентайп. Каждому символу юникода в шрифте могут соответвовать несколько вариантов и задача harfbuzz найти нужный вариант в данном контексте.

Там в описании есть, для языков в которых написание группы из нескольких букв передаётся одним глифом в зависимости от их последовательности. Это тамильский, арабский, иврит и тому подобные. Причём (могу ошибаться) письменные варианты.

Правильно. Это одна из задач text shaping.

HarfBuzz is an implementation of OpenType complex text shaping.

HarfBuzz is a text shaping library. Using the HarfBuzz library allows programs to convert a sequence of Unicode input into properly formatted and positioned glyph output—for any writing system and language.

Many OpenType fonts contain ligatures: combinations of characters that are rendered as a single unit. […] In other words, text shaping involves querying the font’s ligature tables and determining what substitutions should be made.

Other languages involve marks and accents that need to be rendered in specific positions relative a base character.

обращение к Юникод-строке по индексу лишено всякого смысла.

std::u32string смотрит на это с изумлением.

смотрит на это с изумлением.

std::u32string — их тоже нельзя разбивать в произвольном месте. Вдруг там модификатор цвета к эмодзи.

Профит в том, что байты UTF-8 уже правильно декодированы в char32_t.

Меньше - можно. У пробела только один цвет, у полностью залитого квадратика тоже. Больше и правда нежелательно.

В нормальных кодировках диакритика уже прицеплена к символам, а не делается каким-то отдельным префиксом. То, что для отображения строки на экран по их дурацкому стандарту можно не просто уметь декодировать utf, а ещё и лазить по всяким таблицам чтобы узнать, является ли очередная декодированная сущность символом или нет - совершенно убогий подход, вынуждающий тянуть всякий хлам в иначе компактные приложения.

https://github.com/harfbuzz/harfbuzz/pull/5558
первое полетело

Знак ударения всё равно нужно как-то ставить

Угадай, почему его не примут.

и почему же?
не примут — ну увы — буду делать свой нормальный код под енту либу и собирать самому через makepkg в archlinux — всем остальным же и им самим хуже если не примут))

таковой опыт у меня уже имеется — с драйвером (утилитами) ntfs3

И зачем вам понадобился char32_t?

для более быстрого использования мультибайтовых строк?

В нормальных кодировках диакритика уже прицеплена к символам, а не делается каким-то отдельным префиксом.

Диакритика по своему определению отдельна от символа, и может сочетаться с символами в любом сочетании. Невозможно предусмотреть все комбинации символов и знаков. Непрактично кодировать все комбинации гласных и согласных.

для более быстрого использования мультибайтовых строк?

К тексту все равно можно обращаться только последовательно. Расходы на пропуск многобайтных/двусловных символов незначительны по сравнению с затратами на их классификацию.

ну проверок никаких не нужно делать — просто шагаешь и всё... (в отличии от utf-8)

последнее по сути для загрузки и выгрузки использовать (в том числе в/из интерфейса) — внутри программы вообще не обязательно таковым оперировать.

1. декодируем utf8-«стог» в std::u32string (преобразуем регистр, если нужно);
2. декодируем utf8-«иголку» в std::u32string (преобразуем регистр, если нужно);
3. SIMD-оптимизированно ищем результат в декодированном «стогу»;
4. Для новых «иголок» переходим к п. 2;
5. PROFIT!

Да, так и есть. Для европейских языков, китайского, японского и корейского языков HarfBuzz не обязателен. HarfBuzz в первую очередь нужен для языков вроде арабского или хинди, где форма и расположение глифов зависит от позиции в слове.

Строку можно искать побайтово в UTF-8 без декодирования в UTF-32. UTF-8 гарантирует отсутствие ложных совпадений со сдвигом.

В 99.9% случаев нет никакого смысла получать значения кодпойнтов Юникода по индексу.

В 99.9% случаев нет никакого смысла

Никогда этой фразе не верил.

Тогда примеры в студию.

Примеры чего, очевидного? Нет, спасибо.

Какого конкретно использования? Для отрисовки строк используется последовательный доступ. Для поиска можно использовать побайтовый поиск UTF-8 строки.

Непрактично кодировать все комбинации гласных и согласных.

Почему все комбинации? Это же отдельные буквы, у каждой своё знакоместо.

Диакритика по своему определению отдельна от символа, и может сочетаться с символами в любом сочетании.

Почему тогда в дефолтной IBM PC кодировке она прицеплена (во второй половине кодовой таблицы) и этого хватало?

Это задача визуального редактора/просмотрщика, а не кодировки символов.

Для проверки что в 40-й позиции строки стоит правильная сигнатура, например. Такие вещи сейчас не страдают от юникода только потому, что все, кому это нужно, на поддержку юникода просто забивают и считают символ=байт.

Для проверки что в 40-й позиции строки

Откуда взялось это число? Что за хардкодинг? Если использовать strlen(), то всё будет прекрасно работать и с UTF-8 без декодирования кодпойнтов.

Это же отдельные буквы, у каждой своё знакоместо.

Отдельные буквы и знакоместа бывают только на пишущих машинках. В реальных текстах буквы и глифы не соответсвуют друг другу, и их приходится составлять из нескольких частей.

Почему тогда в дефолтной IBM PC кодировке она прицеплена … и этого хватало?

Так хватало, что для IBM PC пришлось создать целых 5 аппаратных кодировок.

Для проверки что в 40-й позиции строки

Что такое «40-я позиция строки»? Что вообще такое «строка»?

ну для utf-8 строки придётся каждый раз делать проверки по стандарту (на количество байт для символа), а с уже преобразованными нет — просто идёшь и всё.

Откуда взялось это число? Что за хардкодинг?

Какая разница? Символы не только для набора художественных текстов используют, а в технических надписях вполне может быть формат с фиксированной шириной колонок. И с этим дурацким utf8 в таких случаях придётся вместо обращения по индексу массива каждый раз считать длину всего что слева от нужной позиции.

Какие проверки? Что с UTF-8, что с UTF-32 идёшь точно также. Значения кодпойнтов программе обычно не нужны. Даже если в консоль выводить и считать знакоместа в консоли, то это делается не через подсчёт кодпойнтов, а особой функцией. Например буквы с ударением или смайлы могут использовать несколько кодпойнтов, но одно место в консоли. И наоборот китайские иероглифы занимать два места в консоли, но один кодпойнт.

Символы не только для набора художественных текстов используют, а в технических надписях вполне может быть формат с фиксированной шириной колонок.

Смотрите мой ответ ниже. Количество мест в консоли в общем случае не относится к количеству кодпойнтов как один к одному. Так что для фиксированных колонок нужна специальная для этого функция подсчёта знакомест в консоли, а не просто длина массива или количество кодпойнтов. Консольные редакторы вроде Nano или Vim учитывают это.

Отдельные буквы и знакоместа бывают только на пишущих машинках. В реальных текстах буквы и глифы не соответсвуют друг другу, и их приходится составлять из нескольких частей.

Это блоатварное ненужное усложнение. Оставь все эти штуки текстовым процессорам, тащить их везде где просто хочется иметь многоязычную кодировку - идиотизм.

Так хватало, что для IBM PC пришлось создать целых 5 аппаратных кодировок.

Какие ещё 5 кодировок? В каком видеоадаптере они были зашиты?

Эм, это типа оправдание?

Смотрите, они сделали пакость ещё хуже, поэтому мелкую пакость, сделанную раньше, мы им простим.

То что знакоместу может соответствовать больше одного символа - это вообще отвратительно, чтобы нормально посчитать длину мало того что надо парсить всё начало строки, так ещё и надо таскать с собой тяжёлые таблицы со свойствами символов и сверяться с ними на каждый распарсенный.

То что знакоместу может соответствовать больше одного символа - это вообще отвратительно

А ничего не поделаешь, особенно для некоторых языков типа китайского. Там иероглифы в два раза шире латинских букв.

Особенности написания того или иного символа должны заботить авторов шрифтов, кодировку это не должно затрагивать.

Если шрифт не моноширинный, то вообще не вижу «состава проблемы». Бывают буквы тонкие (i), бывают широкие (W), и никому в голову не приходила гениальная идея на этом основании устраивать фокусы с количеством знакомест, кроме авторов юникода.

Если шрифт моноширинный - ну, видимо шрифты, имеющие поддержку китайского языка, должны быть условно не 8х16 а 16х16 (конкретный размер выбирает всё равно юзер и он должен соблюдаться). Впрочем засунуть во второй латиницу и кириллицу никто тоже не мешает. А вот делать так, чтобы в зависимости от языка очередного символа ползла текстовая «вёрстка», рассчитанная на моноширинность - это опять какое-то вредительство.

Какие ещё 5 кодировок?

Для США, Канады, Португалии, Дании/Норвегии, Исландии.

В каком видеоадаптере они были зашиты?

В знакогенераторе, используемом CGA и MDA.

никому в голову не приходила гениальная идея на этом основании устраивать фокусы с количеством знакомест

Все южноазиатские терминалы поддерживали моноширинные символы различной ширины.

ну а как ты предугадаешь для utf-8 сколько байтов нужно скипнуть до следующего символа?

Если шрифт моноширинный - ну, видимо шрифты, имеющие поддержку китайского языка, должны быть условно не 8х16 а 16х16

Ну вот там в шрифте латинские символы 8x16, а китайские 16x16. И это по-прежнему считается моноширинным шрифтом, хотя его длину в знакоместах нельзя считать по количеству символов.

Зачем вам следующий символ? И что вы понимаете под символом?

что бы его как либо использовать?