LINUX.ORG.RU

ttf-parser 0.5 — новая библиотека для работы с TrueType шрифтами

 ,


3

8

ttf-parser — это библиотека для разбора TrueType/OpenType шрифтов. В новой версии появилась полноценная поддержка переменных шрифтов (variable fonts) и C API, вследствие чего я решил прорекламировать её на лоре.

До недавнего времени, если была необходимость работы с TrueType шрифтами, было ровно два варианта: FreeType и stb_truetype. Первый является огромным комбайном, второй поддерживает довольно небольшое количество функций.

ttf-parser находится где-то посредине. Он поддерживает все те же TrueType таблицы (формат TrueType состоит из множества отдельных бинарных таблиц) что и FreeType, но не занимается отрисовкой самих глифов.

При этом, ttf-parser содержит множество других значительных отличий:

  1. ttf-parser написан на Rust без использования unsafe. FreeType и stb_truetype написаны на C.
  2. ttf-parser является единственной безопасной (memory-safe) реализацией. Чтение произвольной памяти невозможно. Во FreeType постоянно исправляют уязвимости, а stb_truetype в принципе не предназначен для чтения произвольных шрифтов.
  3. ttf-parser является единственной thread-safe реализацией. Все методы парсинга константны. Единственным исключением является задание координат для переменных шрифтов, но эта функция reentrant. FreeType в принципе однопоточный. stb_truetype - reentrant (можно использовать отдельные копии в разных потоках, но не одну из множества).
  4. ttf-parser является единственной реализацией не использующей аллокации в «куче». Это позволяет ускорить разбор и избежать проблем при OOM.
  5. Также, почти все арифметические операции и приведение числовых типов проверяются (в том числе статически).
  6. В самом худшем случае библиотека может бросить исключение. При этом в C API исключения будут перехвачены и функция вернёт ошибку, но не упадёт.

И несмотря на все гарантии безопасности, ttf-parser также является и самой быстрой реализацией. Например разбор CFF2 в 3.5 раза быстрее чем в FreeType. Разбор glyf тем временем на 10% медленнее чем в stb_truetype, но это из-за того, что он не поддерживает переменные шрифты, для реализации которых требуется хранить доп. информацию. Больше подробностей в README.

>>> Подробности

★★★★★

Проверено: Satori ()
Последнее исправление: Satori (всего исправлений: 1)

Ответ на: комментарий от toyo-chi

А как там вообще в целом Redox? Готов ли хоть для чего-нибудь?

у них скорей всего нет цели сделать готовый продукт, иначе они бы начали с ОС для сетевых устройств типа роутеров и RISC-V а не доисторический x86.

anonymous
()

f-parser написан на Rust без использования unsafe.

Зачем так, ведь тормозить будет, с тем же успехом на Джава написать можно было :)

bonta ★★★★★
()
Ответ на: комментарий от RazrFalcon

На выходе обычные кривые Безье.

Во, джва года ждал такую либу. У freetype главный недостаток в том, что она рисует по одному из нескольки алгоритмов. А мне нужна более гибкая настройка, тени там всякие, обводки. Что-то гдето видел с калбеками на строчную развертку вроде, но там непонятно непосвященному.

q0tw4 ★★★★
()
Ответ на: комментарий от bonta

с тем же успехом на Джава написать можно было

Тролль 80 лвл?

1) Нахрена парсеру unsafe вообще сдался, там же одна логика

2) Нахрена парсеру шрифтов быть быстрым, он же при старте программы текстуру заполнил и больше не нужен (разве что конфиг поменяют)

3) Попробуй либу на джаве заюзать из С++ проджекта, посмотрим сколько вазелина потребуется после того как начальник об этом узнает.

q0tw4 ★★★★
()
Последнее исправление: q0tw4 (всего исправлений: 1)
Ответ на: комментарий от mertvoprog

Боюсь узнать, что оно делает, а главное зачем, не удасться. Автор что-то скрывает.

anonymous
()
Ответ на: комментарий от RazrFalcon

Пилите, Шура. Замену всему стеку сразу, главное чтоб без unsafe. У всех панго что-то делает, а у него нет. Вот и найди слабое звено после этого.

anonymous
()

stb_truetype достаточно медленный. Скорость работы freetype зависит настройки модулей.

А вот в чем смысл парсера без растеризатора мне непонятно.

andreyu ★★★★★
()
Ответ на: комментарий от q0tw4
  1. Нахрена парсеру шрифтов быть быстрым, он же при старте программы текстуру заполнил и больше не нужен (разве что конфиг поменяют)

Весь диапазон Юникода? Сколько лет будете ждать старта приложения и какой размер атласа для этого потребуется?

andreyu ★★★★★
()
Ответ на: комментарий от mertvoprog

Просто свойства шрифтов вытаскивает

Это как раз и не просто.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от q0tw4

FreeType тоже умеет кривые выдавать, но API у него наркоманский.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от andreyu

О каких настройках freetype идёт речь?

RazrFalcon ★★★★★
() автор топика
dron@gnu:~/type$ git clone https://github.com/RazrFalcon/ttf-parser.git
Клонирование в «ttf-parser»…
remote: Enumerating objects: 934, done.
remote: Counting objects: 100% (934/934), done.
remote: Compressing objects: 100% (472/472), done.
remote: Total 2113 (delta 675), reused 705 (delta 458), pack-reused 1179
Получение объектов: 100% (2113/2113), 1.18 MiB | 2.17 MiB/s, готово.
Определение изменений: 100% (1549/1549), готово.
dron@gnu:~/type$ cd ttf-parser/
dron@gnu:~/type/ttf-parser$ ls
benches     CHANGELOG.md  LICENSE-APACHE  scripts      testing-tools
c-api       examples      LICENSE-MIT     src
Cargo.toml  fonts         README.md       test-all.sh
dron@gnu:~/type/ttf-parser$ cargo build 
    Updating crates.io index
 Downloading log v0.4.8                                                         
 Downloading cfg-if v0.1.10                                                     
error: unable to get packages from source                                       

Caused by:
  failed to parse manifest at `/home/dron/.cargo/registry/src/github.com-1ecc6299db9ec823/cfg-if-0.1.10/Cargo.toml`

Caused by:
  feature `rename-dependency` is required

this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["rename-dependency"]` to enable this feature

Куда это вписывать?

cargo-features = ["rename-dependency"]

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

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Первый раз такое вижу. Если верить гуглу - у вас какая-то борода с инетом. Как вариант можно попробовать cargo build --no-default-features, чтобы он не качал зависимости.

По контурам - см. examples/font2svg

RazrFalcon ★★★★★
() автор топика
Последнее исправление: RazrFalcon (всего исправлений: 1)

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

q0tw4 ★★★★
()
Ответ на: комментарий от RazrFalcon

Не, с инетом всё нормально. Обновлю всё попозже и ещё попробую

По контурам - см. examples/font2svg

Спасибо.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от q0tw4

через тесселяционные шейдеры

Накой хрен они нужны? Когда есть обычные Фрагментные? Можно наверное даже вообще в VBO загнать и отразить геометрию на текстуру. Один хрен это делать 1 раз надо. Или я не понял что ты хочешь

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

Еще не плохо было бы сварганить версию с Error енумом, особенно если добавить туда создание шрифтов…

q0tw4 ★★★★
()
Ответ на: комментарий от RazrFalcon

Пробуй, авось и получится что-нибудь стоящее.

Linfan ★★★★★
()

Лишь бы наркоманией не занимался… А вообще, дрочепотень какая-то.

anonymous
()

А вообще Флакон дело делает. Нашел себе нишу и пилит. Глядишь свой локальный Беллар’ вырастет :) Респект короче

yoghurt ★★★★★
()
Последнее исправление: yoghurt (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

А зачем там Error

Как зачем. Надо же упасть если вдруг диск попортился.

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

Ну если даже подгружать символы по мере надобности, всеравно особо спешить некуда

При 60 fps на весь кадр уходит всего 16мс. Так что спешить есть куда.

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

и зачем парсить шрифты в потоке рендеринга? Они же нужны только когда узер нажал на новую клавишу или подвинул картинку.

q0tw4 ★★★★
()

является единственной реализацией не использующей аллокации в «куче»

Интересно. А stack overflow принципиально возможен?

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

В теории - да. Но в реальности вряд ли. Я не больше пары КБ стека использую.

В будущем я планирую убрать все рекурсивные функции (сейчас они все имеет ограниченную глубину), но пока что это проблематично из-за особенностей TrueType.

RazrFalcon ★★★★★
() автор топика
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от q0tw4

и зачем парсить шрифты в потоке рендеринга? Они же нужны только когда узер нажал на новую клавишу или подвинул картинку.

Речь не о парсинге, а о растеризации нужного глифа в тот момент, когда он понадобился. Ваш КО.

andreyu ★★★★★
()

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

А могли бы полезным делом заняться. Решать реальные проблемы людей.

anonymous
()

является единственной реализацией не использующей аллокации в «куче». Это позволяет ускорить разбор и избежать проблем при OOM.

Чушь и ахинея.

anonymous
()
Ответ на: комментарий от andreyu

А вот в чем смысл парсера без растеризатора мне непонятно.

Поиск ошибок в созданных шрифтах. Классика жанра: глифы без точек экстремума и с самопересечениями.

AP ★★★★★
()
Ответ на: комментарий от anonymous

Бред, оптимизация не на уровне языка работает. А вот с const ты в дебаге без оптимизации явно указывешь, что надо делать копию.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.