Безопасность это хорошо, но чтобы нарисовать глиф всё равно придется обращаться к небезопасным stbtt и ft2?

Какие-то планы на отрисовку есть?

Отрисовку пилят люди из RustType. Я тут не при чём и влазить туда пока не планирую.

Если нужно тупо нарисовать глиф - есть raqote. Но мы же хотим нормальный хинтинг и антиалиасинг. А значит нужно ждать пока кто-то соберётся запилить нормальный freetype.

How portable is FreeType 2? The FreeType 2 source code is extremely portable for the following reasons:

Everything is written in standard ANSI C.

We are very pedantic to avoid any kinds of compiler warnings. The current source code has been compiled with many compilers without producing a single warning.

The library doesn’t use any static writable data at all, making it an ideal choice on various embedded systems (e.g., it can be run from ROM directly). It is completely thread-safe too.

We have made great efforts to ensure that the library is efficient, compact, and customizable.

ну и про memory-safe тоже враньё. так нагло врать - это так себе, примерно уровень днища, расчёт на лохов.

Ну так TrueType или SFNT? Довольно странно делать парсер SFNT, но только TrueType.

SFNT - слишком для избранных. Про ttf знаю все.

Где-ты это откопал, болезненный? Открываем офф доку и видим:

https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#ft_library

In multi-threaded applications it is easiest to use one FT_Library object per thread. In case this is too cumbersome, a single FT_Library object across threads is possible also, as long as a mutex lock is used around FT_New_Face and FT_Done_Face.

https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#ft_face

An FT_Face object can only be safely used from one thread at a time. Similarly, creation and destruction of FT_Face with the same FT_Library object can only be done from one thread at a time.

тебя в гугле забанили?

https://www.freetype.org/freetype2/docs/ft2faq.html#general-portability

Открываем офф доку и видим:

фигу

1. Авторы не различают thread-safe и reentrant.
2. Last update: 25-Feb-2011

Быстрее, безопаснее и фичастее? Нужно!

Ну так это же слоган Rust’a:

Safe, fast, concurrent - pick three.

ttf-parser является единственной безопасной (memory-safe) реализацией.

Каждый раз когда читаю такое, вспоминаю про «Memory Leaks are Memory Safe» и проигрываю

ttf-parser не алоццирует в принципе. Шах и мат.

Тоесть разожранное днище с безумным количеством кода для реорганизации памяти во имя «неалоцировать»? 70ые какието... Бабушкины коврижки а не ПО

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

Пермиссивщина.

Прокольная штука. Особенно радует, что библиотека не пытается сама память выделять, идеально ложится на кастомные аллокаторы. Спасибо, что поделился.

Юниксвейнинько, крассавчик.

Зачем нужна эта библиотека автор может пояснить в двух словах?

man stack

Парсить TrueType шрифты. Ваш КО.

Без понятия.

хотим нормальный хинтинг и антиалиасинг

Эх, хотим, но сам я бы такое не стал писать. :(

stbtt из-за этого очень сильно проигрывает freetype.

Я в целом удовлетворён работой freetype, но честно говоря в код его не лазил и не особо хочется. Работает и хорошо.

Ну меня freetype не устраивает, ибо очень жирный, неудобно использовать из Rust и с многопоточностью боль. А мне оно в первую очередь нужно для resvg, где хинтинг бесполезен.

код его не лазил

А я лазил. Типичный сишный ад и Израиль.

Молодца

Прокольная штука

Прокольная

Хм…

Отлично, распарсил, что дальше с этим? Это middleware для чего-то большего или просто поделка для тренировки?

Блин. Не хотел. Пальцы заплетаются уже.

Зачем вообще писать либу, которая мне не нужна? ttf-parser используется в resvg, rustybuzz и rusttype (ещё не смерджили в мастер).

Джавист?

Авторы не различают thread-safe и reentrant.

Да вроде как различают. Сама библиотека заявлена как thread-safe, в то время как отдельные объекты - нет. Противоречия нет

То есть отсутствие статических переменных делает её thread safe? Ну такое.

ttf-parser не алоццирует в принципе. Шах и мат.

std::vector<char> data((std::istreambuf_iterator<char>(s)),
                        std::istreambuf_iterator<char>());
m_fontData = std::move(data);

m_font = ttfp_create_font(m_fontData.data(), m_fontData.size(), index);

Пропущен const, из-за этого компилятор не сделает оптимизацию. std::move здесь не нужен, это всего лишь каст к &&, если компилятор может сделать мув, то он его сделает сам, надо добавить const и включить оптимизации. О3 или хотя бы О2. В бенчмарке stb на каждый глиф выделяется и освобождается память, бенчмарк меряет не скорость аутлайна, а скорость алокаций. И т.д.

Показывайте результаты с вашими изменениями.

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

Вы не понимаете. В этом и есть сама суть и сам смысл подобных импульсов. Растофанаты просто не могут, не способны изъясняться честно и написать «данная поделка хороша тем что моя и малинкой пахнет». Ведь так бы не было никаких вопросов и возможно, адекватные люди бы ей заинтересовались.

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

лаба1 используетца в лаба2, лаба3, лаба4 (зачёты ешчё не получил, поэтому это не точно)

перевёл для белых людей.

кто-то соберётся запилить нормальный freetype

А потом захочется поддержки всего разнообразия языков ЮВА и будете ждать, когда кто-то запилит Pango со всеми дополнительными библиотеками :)

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

если компилятор может сделать мув, то он его сделает сам

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

std::move здесь не нужен

std:: не нужен :D move нужен.

Чушь какую-то ты написал.

Ладно б посоветовал у вектора assign позвать…

Ну а если серьёзно, зачем парсить ttf если его не рендерить потом?

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

Парсить без отрисовки есть смысл, но с этим замечательно справляется harfbuzz

Замену pango я уже и так пилю. Точнее замену harfbuzz. Панго особо ничего не делает.

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

Конечно быстрее, без валидации входных данных-то.

Рендерить будет либа, которая использует ttf-parser. man unix way.

Там в функцию передаётся структура:

typedef struct ttfp_outline_builder {
    void (*move_to)(float x, float y, void *data);
    void (*line_to)(float x, float y, void *data);
    void (*quad_to)(float x1, float y1, float x, float y, void *data);
    void (*curve_to)(float x1, float y1, float x2, float y2, float x, float y, void *data);
    void (*close_path)(void *data);
} ttfp_outline_builder;

а функция, по всей видимости, дёргает эти колбеки в нужной последовательности.

Это следующий этап. Надо убрать мусор из кода чтобы понять, что там не надо сначала делать копию, а потом ее мувать.

Да, пацаны, С++ - это реально сложно осилить, я понимаю почему есть спрос на язычки попроще. Сам не знаю как так получается, что люди пишут все эти кракозябры вместо нормального кода, что-то здесь не так. Есть подозрение, что он просто взял пример с stackoverflow и несколько раз скопипастил.

Что оно делает? Просто свойства шрифтов вытаскивает, или может рендерить? Мы тут собирались как раз делать конвертер картинок в портянки из Emoji (обнаруженные решения почему-то гадят ими на страницу с абсолютными координатами, а не формируют текстовую сетку). И как раз на Rust.