#harfbuzz

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1220100263

Маски, наконец-то, сброшены, и владелец проекта сказал(как и нужно было сказать с самого начала!), что с этим ничего поделать нельзя.

В общем-то, и понятно, им нужно или:

* Перепиливать интерфейсы друг у друга через DI(https://en.wikipedia.org/wiki/Dependency_inversion_principle)

* Или сливаться в пламенном экстазе в одну библиотеку

Очевидно, ни то, ни то, - не случится.

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1369649173

#harfbuzz

На этот раз в тикет пришел великий и ужасный Матиас Класен (я правильно транслитерировал?) - это тот человек, который виноват во всем плохом, что случается в #gtk и #gnome, и снова рассказал, что "ничего нельзя сделать", но я так просто их не отпущу :))

Шапито продолжается, потому что, с выходом новой версии #harfbuzz появилась зависимость harfbuzz -> cairo, и у нас теперь тройной цикл:

cairo -> freetype -> harfbuzz -> cairo.

"New hb-cairo API for integrating with cairo graphics library. This is provided as a separate harfbuzz-cairo library. (Behdad Esfahbod, Matthias Clasen)"

Набижал в тикет - https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1426898625

Тут, конечно, все несколько проще, потому что это отдельная либа в той же репе, but still.

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1437382934 #harfbuzz

Потрындел с matthiasclasen и behdad про эту circular dep.

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

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

В мой любимый тикет про #harfbuzz пришел ncopa, https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1514618751, пишет, что:

"As a distro maintainer for Alpine Linux, ABI breaks are trivial to handle compared to circular dependencies. And we handle ABI breaks all the time. Circular dependencies on the other hand always end up with some hackish and fragile solution"

Вот полностью с ним согласен, хотя, конечно, кому как.

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

Кстати, пишу так "ncopa", как будто все должны знать, кто это такой. Это создатель Alpine Linux. А я, по роду деятельности, пересекаюсь с ним во всякой своей ticket work чуть ли не еженедельно.

https://github.com/harfbuzz/harfbuzz/pull/4131

#harfbuzz #fontconfig #wasm

"This adds a wasm shaper that when called (default, when built), loads a WebAssembly program from the Wasm table of the font and calls its bool shape(font*,buffer*) function to shape the buffer"

Я, с одной стороны, всячески пропагандирую "открытые" системы, типа "там, где передаешь строку, сразу передай user defined dict", или "если требуется процедурное действие, не формализуй его, а позови пользовательский run.sh", но, с другой стороны, понимание, что загрузчик шрифта может позвать произвольный WASM, даже и в песочнице, меня напрягает.

Мысль о том, что интерпретатор wasm будет влинкован в каждую программу, энтузиазма тоже не вызывает. Вот если бы шрифты рендерились отдельным процессом, например, через dbus, было бы гораздо более хорошо.

#wasm #harfbuzz

Не прошло и месяца после коммита с поддержкой wasm шейперов, как код проехал в прод - https://github.com/harfbuzz/harfbuzz/releases

(кстати, в прошлом тексте я ошибся, предположив, что код будет заниматься рендерингом - код будет заниматься исключительно шейпингом текста, то есть, расстановкой шрифтовых глиф по холсту - пример того, что было до, и после - https://github.com/simoncozens/wasm-examples)

Все это плохо пахнет, если вы понимаете, о чем я:

* мало времени от демонстрации намерений до релиза, как будто кто-то не (напомню, harfbuzz пилит сотрудник Гугла на зарплате) хотел серьезного обсуждения этой фичи.

* https://github.com/harfbuzz/harfbuzz/blob/main/docs/wasm-shaper.md - поверхность взаимодействия этого кода с harfbuzz весьма широка, и я не уверен, что ее можно норм реализовать, если ты - не harfbuzz. Похоже на попытку запилить очередной vendor lock in - если хотите использовать крутой шейпер из шрифта, берите harfbuzz. И чем это пижже ситуации с интерпретатором байткода из TrueType шрифтов? Отделаться тут общими словами "ну это только незначительные улучшения шейпера" - так не выйдет, потому что вот даже тут уже показано, как таки заэмбеддить настоящий растеризатор шрифтов в такой программируемый шрифт - https://github.com/simoncozens/wasm-examples

Ну и, конечно, все примеры таких программных шейперов запилены на Rust, хотя, конечно, тут сложно было ожидать чего-то другого:

* wasm target в Rust запилен много лучше, чем в других языках, хотя бы потому, что С++ в #wasm положить тяжело, так как в нем нет никакой поддержки для setjmp/longjmp/прочих способов нелокального code path (e.g. исключений)

* хайп, куда же без него

Короче, задолбался я вырезать лобзиком сборку цикла cairo -> #fontconfig -> #freetype -> #harfbuzz -> (cairo + freetype + fontconfig), и сделал по рабоче-крестьянски:

Сначала собираем все 4 цели в #bootstrap варианте, без зависимостей друг на друга.

Потом собираем все 4 либы, прописывая им зависимость времени сборки(это важно! зависимости будут доступны при сборке, но не при дальнейшем использовании!) от всех других 3 библиотек:

https://github.com/stal-ix/ix/blob/main/pkgs/lib/harfbuzz/unwrap/ix.sh#L3-L8

Потом собираем кадавра из 4 библиотек, lib/harfbuzz:

https://github.com/stal-ix/ix/blob/main/pkgs/lib/harfbuzz/ix.sh#L3-L8

Ну и все остальные библиотеки из цикла - это просто алиасы на lib/harfbuzz:

https://github.com/stal-ix/ix/blob/main/pkgs/lib/freetype/ix.sh#L4

Сборок чуть больше, но геморроя с вырезанием лобзиком сильно меньше.

А эти пусть как жили во грехе, так пусть и живут.

https://monaspace.githubnext.com/

Новые #monospace шрифты от github, а это всегда событие!

Из интересного, и чего я раньше не встречал:

"Texture healing works by finding each pair of adjacent characters where one wants more space, and one has too much. Narrow characters are swapped for ones that cede some of their whitespace, and wider characters are swapped for ones that extend to the very edge of their box. This swapping is powered by an OpenType feature called “contextual alternates,” which is widely supported by both operating systems and browser engines"

В каком эмуляторе терминала это работает, кто за это отвечает (#harfbuzz?), и как проверить,что оно срабатывает - я пока не понял.

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1835439173

#harfbuzz

Вот, кто-то еще заметил, что там цикл уже существенно больше, чем просто hb <-> freetype.

Понятное дело, что ничего там не произойдет, потому что никто, кроме его работодателей, повлиять на разработчика harfbuzz не может. А им, очевидно, похуй, пока он исправно проталкивает нужные изменения в downstream дистрибутивов.

Я ору, и не могу остановиться. #harfbuzz

Как обычно, решил влезть в дискуссию, и сказал, что так-то есть дофига способов разорвать эту circular dep, было бы желание - https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1837576427

На что я получил кучу ожидаемой чепухи про ABI, https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1839281781

И, самая мякотка:

"That's a more feasible solution IMO. @lemzwerg would you be open to dlopening libharfbuzz? If not, we might consider it on our side"

Пиздец, я хочу, чтобы в этом мире было меньше хаков с dlopen, а коллега, на голубом глазу, предлагает разорвать этот цикл черз dlopen...

АААА!!!

#harfbuzz #AI

Нам тут подсказывают с задних рядов, что, не прошло и года (нет, реально, всего несколько дней не хватило), как умельцы положили в этот шейпер на #wasm какую-то там LLM модель - https://fuglede.github.io/llama.ttf/

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

Тем не менее, размах мысли завораживает!

https://behdad.org/text2024/

Совершенно монументальный обзор про состояние разного рода "технологий отрисовки текста", от автора #harfbuzz.

Читал его внимательно, несколько дней, и что я имею вам сказать:

* harfbuzz всех победил, в том числе, в продуктах Adobe, Microsoft, Apple, и так далее.

* И, что более интересно, всех победил Google, как основной разработчик harfbuzz, и как автор победивших всех браузера.

А самое интересно, что у Google есть наполеоновские планы на "технологии отрисовки текста" - переписать все на Rust, ага:

https://github.com/googlefonts/oxidize

"While my proposed use of flatfonts fell flat on its face, better ergonomics for building and consuming fonts have lived on in terms of Google’s Oxidize effort to port both font compilation and font consumption (font access initially, followed by shaping) platform to the Rust programming language"

https://github.com/googlefonts/fontations/tree/main/skrifa
https://github.com/googlefonts/fontations/tree/main/klippa

"FreeType is to be replaced by fontation’s skrifa. Subsetting by klippa. Fontations does not itself contain a rasterizer (currently), but relies on existing graphics systems for rasterization"

"HarfBuzz is most likely to be replaced by RustyBuzz, by Yevhenii Reizner (RazrFalcon), in the Rust ecosystem. RustyBuzz uses Yevhenii’s ttf-parser for font access. There is desire to port RustyBuzz to use fontations instead"

https://github.com/RazrFalcon/rustybuzz

"Fontconfig-compatible font selection half-libraries exist in terms of fontdb by Yevhenii Reizner and the experimental fontique from the Oxidize team"

Ну вы поняли, к чему все идит, да?

Вишенка на торте - https://github.com/harfbuzz/harfbuzz-wasm-examples, пример того, зачем в harfbuzz добавили WASM для программного шейпинга. Выглядит интересно.

https://t.iss.one/itpgchannel/2064 - все одно к одному...

Будни #bootstrap, #rant

Продолжу тему "gobject introspection" #gir

Во-первых, я собрал vala.

https://vala.dev/

Ну потому что нужно же как-то развивать набор тулчейнов, и мне показалось, что, локально, мне больше всего профита будет от vala, на нем прилично написано gtk приложений.

Но собрать что-то содержательное им оказалось весьма сложно, потому что с внешним миром код на vala общается именно через gir.

А вот эти вот интерфейсные правила собираются очень хрупким образом - частично это парсинг исходников (а там дальше много интересного - какой препроцессор взять, clang, или gcc, какие туда передаются опции, и так далее), и частично - через загрузку интроспектируемого кода в специальном режиме, когда мы просим бинарник выплюнуть все сведения о зарегистрированных в нем типах в виде .gir файла (прощай, кросс-компиляция, ага).

С одним набором настроек собирается gir для libadwaita, но не собирается для libhandy или #harfbuzz (не спрашивайте). Пофиксил - отваливается что-то третье.

Собрать консистентно все gir для всех гномовых либ я пока не сумел, у меня нет столько времени.

В конце-концов, я нашел вот эту вот репку - https://github.com/gtk-rs/gir-files

Здесь растоманы прикопали все более-менее популярные gir. Ну потому, что они в своей cargo вряд ли смогут как-то разумно воспроизвести все условия для того, чтобы повторить эти гномьи экзерсизы. Ну и обновляют их руками, по мере необходимости.

Ну я и присоседился, беру эти файлы у них.

Вроде, как-то оно работает, но весь этот техпроцесс вызывает сомнение.

#llvmweekly #rant

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696

TL;DR - хочется уметь красиво выводить в отладчике не встроенные типы, для этого предлагается завести секцию, в котороую писать bytecode, который умеет выводить на эран те или иные типы в программе.

Почему не положить туда готовые python форматтеры, которые уже есть, и написаны?

"The logical next step would be to store full Python formatters instead of summary strings, but Python code is larger and more importantly it is potentially dangerous to just load an execute untrusted Python code in LLDB.

To address these problems, I’m proposing a minimal bytecode tailored to running LLDB formatters. It defines a human-readable assembler representation for the language, an efficient binary encoding, a virtual machine for evaluating it, and format for embedding formatters into binary containers"

Объяснение не стоит и выеденного яйца, потому что ТЫ УЖЕ ЗАПУСТИЛ этот бинарь, запусти и Python, в песочнице.

https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/10

Или возьми готовый VM, в который llvm уже умеет (hint - #WebAssembly, #bpf, #ebpf https://discourse.llvm.org/t/a-bytecode-for-lldb-data-formatters/82696/12).

Но нет, это было бы слишком просто, на таком фиолетовое не получить.

Вообще, удивительно, в маленький #harfbuzz тащат большой #WebAssembly (https://t.iss.one/itpgchannel/1201), а в большой LLDB (который уже умеет в #WebAssembly) тащат самопальный байткод...

Где логика-то?

Будни #bootstrap

В общем, я сумел, по модулю #gir для gdk-pixbuf.

Я хз, как у них там все сделано в их CI, но у меня не получилось воспроизвести их техпроцесс так, чтобы он давал такой же результат, как у них.

После того, как я продрался через все хитросплетения их говноскриптов, в сухом остатке у меня случился вот такой вот diff, между их результатом, и моим:

- <type name="pid_t" c:type="pid_t"/>
+ <type name="gint" c:type="pid_t"/>

В их техпроцессе где-то есть нормализация pid_t (про который их код ничего не знает), до gint, про который их код что-то знает.

Дальше эта разница "пробулькивалась" по куче сгенеренных файлов, и приводила к их частичной неработоспосбности (просто часть сгенеренных методов становилась недоступной).

Их магию про это я не нашел, но долил немного своей - https://github.com/pg83/ix/blob/main/pkgs/bld/gir/fix/scripts/fix.sh.

Угу, прошелся регулярочкой поверх, и дальше это все как-то заработало.

finita la commedia

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-2784699109

Кольцо и кольцо, какое кому дело?

#harfbuzz

Ссука, они это таки сделали (замели цикл под ковер dlopen) - https://gitlab.freedesktop.org/freetype/freetype/-/merge_requests/361/diffs

#facepalm #harfbuzz

https://www.phoronix.com/news/libinput-Lua-Plugin-System

https://who-t.blogspot.com/2025/05/libinput-and-lua-plugins.html

"The libinput input handling library that's used by both X11 and Wayland based environments on the Linux desktop is preparing to introduce a Lua-based plug-in system. Via Lua scripts it will be possible to modify evdev input events / input device behavior to deal with quirky/broken input devices and better workaround other problems that aren't currently easily addressable"

Слушайте, а вот это прямо очень "вкусно".

Для Linux есть довольно прилично демонов, которые умеют remap событий от evdev.

Хороший список есть у Arch - https://wiki.archlinux.org/title/Input_remap_utilities.

Я перепробовал literally весь этот список, и у всех программ из него есть одна неприятная особенность - они очень opinionated относительно того, что умеют делать. Вот есть у них свой кастомный DSL, и то, что он может выразить - то может, а все, что за рамками - идет лесом. Остановился, кстати, на https://github.com/KarsMulder/evsieve.

Поэтому такой вот micro framework прямо в libinput - это прямо очень, очень хорошо.

Можно было и #WASM, тем более, он уже линкуется в любое GUI приложение, вместе с #harfbuzz (https://t.iss.one/itpgchannel/1201), но lua тоже заебись:

"So why Lua? Because it's very easy to sandbox. I very explicitly did not want the plugins to be a side-channel to get into the internals of libinput - specifically no IO access to anything. This ruled out using C (or anything that's a .so file, really) because those would run a) in the address space of the compositor and b) be unrestricted in what they can do. Lua solves this easily. And, as a nice side-effect, it's also very easy to write plugins in"