LINUX.ORG.RU

resvg 0.7 — библиотека отрисовки SVG

 , ,


1

4

Вышел новый, значительный релиз библиотеки для растеризации SVG - resvg.

Основные изменения:

  • Полностью новая реализация отрисовки текста:
    • Почти весь стек от символа до кривой Безье теперь реализован на Rust: подбор шрифтов (font matching and fallback), парсинг TrueType, расстановка кластеров глифов по правилам SVG (SVG text layout). Исключением является шейпинг (text shaping), для которого используется HarfBuzz.
    • Текст теперь будет конвертироваться в кривые Безье до рендеринга. То есть бекенд отрисовки теперь не обязан поддерживать текст.
    • Поддержка двунаправленного текста (BIDI reordering). Пример.
    • Поддержка textPath. Пример 1, пример 2.
    • Поддержка writing-mode (вертикальный текст). Пример.
    • Корректная поддержка word-spacing и letter-spacing. Пример.
  • Новый, экспериментальный бекенд - Raqote (отдельное спасибо jrmuizel). Raqote - это графическая 2D библиотека, написанная на Rust. Она находится в начальной стадии разработки, при этом её возможностей уже достаточно для использования в resvg. Основным её преимуществом является то, что resvg теперь можно собрать ровно с одной не-Rust зависимостью - HarfBuzz.
  • Поддержка shape-rendering, text-rendering и image-rendering.
  • Ускорена отрисовка растровых изображений.
  • Общее количество тестов достигло 1112-х. Количество успешно пройденных тестов у Inkscape и librsvg упало за 75%.
  • Множество мелких исправлений и улучшений.

Результаты тестирования. Сравнительная таблица.

>>> Репозиторий

★★★★★

Проверено: Shaman007 ()

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

Василий Иванович ест мясо, Анка ест рис, Петька ест капусту - по статистике все трое едят голубцы. Лучше поясни, почему по реальному проекту НЕЛЬЗЯ говорить об используем там языке (щито? Как это?) и причем тут статистика? Не, я понимаю, как разраб, что после мучительных написания и отладки кода, будешь как утёнок, чем угодно аргументировать свой выбор стека, но всё-таки?

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

У меня приложение на Qt. Зачем мне вызывать твою библиотеку, которая будет использовать backend-qt чтобы отобразить, если я могу сразу вызвать QtSVG без плясок с конвертацией между языками?!

Пока не будет переписаны на раст хотя бы 51% всего софта созданного за 30 лет на С/C++, особенно базового, Rust можно закапывать, да хоть уже сейчас.

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

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

Не при чем. Просто дана сравнительная таблица ресурсов при компиляции для разных версий - на си и на расте. Разница в 11 минут времени и более 1.2 гига по кэшу...впечатляет.

Если автор решил набрать 100500 зависимостей

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

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

Бедный Пьер, как только его не называли. Жаль, что из-за неграмотных НЕвиртуалов, у которых все враги, особенно те, кто не прыгает с щенячьми восторгом, он в гробу вертится - таки заслужил человек покоя, полноценную предметную область построения кривых все-таки разработал.

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

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

baist ()
Ответ на: комментарий от zamazan4ik

А зачем в каждой второй строчке упоминать, что написано на Rust? Я вот уже который тред никак не могу понять, зачем так пишут.

это сектанты, у них такой ритуал. у них там даже менеджер пакетов называется «карго», карго-культ, вот это всё.

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

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

Ну это только при двух условиях: 1) набор поддерживаемых фич в движках совпадает (ну там всякие новомодные SVG2) и 2) в моем коде отрисовки нет багов (один ты мне уже репортил, я его кстати починил)

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

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

linuxnewbie ()
Ответ на: комментарий от baist

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

mord0d ()
Ответ на: комментарий от baist

Меняет и очень многое. И не вижу проблемы в использовании unsafe.

Предположим, есть заковыристая либа на расте без unsafe. Затем создаю небольшую производную либу тоже на расте, но с сишными хедерами для интеграции с языком си, например, чтобы из питона вызывать раст и вызывать сам питоний код из раста. Что плохого в том, что в промежуточной растовской либе будет много unsafe, если весь основной код работает и написан на «безопасном» расте?

Или если ты захотел использовать MPI из раста. Тебе нужна все равно прослойка с unsafe, хотя сам основной код тоже может быть на безопасном расте.

Могут быть и другие примеры.

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 2)
Ответ на: комментарий от baist

Тогда зачем нужен этот язык?

Чтобы уменьшить объём потенциальных ошибок работы с памятью?

Чтобы дать реализацию современных практик C++ без оглядки на legacy?

Как связаны libc и lazy_static, bitflags?

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

Я имел в виду, как lazy_static и bitflags связаны с Си?

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

Можно, но программистам лень

Вот как раз не совсем и лень. Постоянно появляются все новые и новые 100%-растовые клоны сишных либ. Другое дело, что функционалом они зачастую не блещут и бедным узерам приходится от них отказыватся в пользу старых добрых биндингов.

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

Тут показывается реальное использование языка, а не хеллуворлды.

Например для С++ по коду boost будем оценивать типичный прикладной код :)

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

без плясок с конвертацией между языками

Все пляски с конвертацией остаются в исходном коде. В машинном коде библиотеки никаких конвертаций нет и этот код мало отличается от кода скомпилированного тем же с++.

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

Пока не будет переписаны на раст хотя бы 51% всего софта созданного за 30 лет на С/C++, особенно базового, Rust можно закапывать,

Пока на лор не перейдут хотя бы 51% всех пользователей хабра/опеннет особенно анонимусы, лор можно закапывать,

Исправил.

technic93 ()
Ответ на: комментарий от baist

rust и есть по большому счету С с альтернативным синтаксисом и синтаксическим транслятором фронтэндом к llvm. Исторически так сложилось что $defaultname язык это С. Было бы глупо переписывать библиотеки на rust тратя на это время если вы можете легко их использовать оборачивая в свой rust-безопасный мирок. Подумайте над тем что вы написали, если бы с выходом каждого языка мы бы все переписывали на новый язык это было бы полным фиаско учитывая что в итоге вы бы получали такие же статически или динамически связываемые библиотеки, смысл?

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

Это как это ты обернешь сишный код в расте? Через unsafe, что ли? Так что либо переписывать на расте, либо пользоваться небезопасными библиотеками. По другому никак.

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

Я понимаю к чему вы клоните, к тому что народ продолжает юзать функционал С, ну так и С++($аny_language_name) продолжает так что туше.

Свой код ты пишешь на обычном rust, любой код который вы получаете в виде библиотеки для связывания можно считать «небезопасным», какая мне разница был он собран из rust исходников или из C исходников. Зачем мне переписывать libc на rust чтобы получить то же по сути? На любом языке используя связываемый нативный код вы соглашаетесь с тем, что это небезопасно, но почему-то судя с ваших слов для rust это крах, а для того же с++ когда, он берет libc нет, или например для js когда оно работает в связке с node.js которое по сути v8 + libevent, может быть это крах js? Может со временем стандартная библиотека rust станет богаче и люди откажутся от libс и что вы там еще перечисляли, опять же банально многим проще брать биндинги из-за предыдущего опыта, как например с тем же libcurl типичная «народная» библиотека и это совершенно не говорит о том что это крах rust.

rust это не какая-то волшебная хрень которая делает любую программу или библиотеку написанную на нем безопасной, он просто ставит вам палки в колеса, когда вы пишите нативный код плохо и опасно, что делает его более-менее рабочим без необходимости потом еще его гонять через статические анализаторы, санитайзеры, отладчики чтобы убедиться в том, что вы себе не отстреливаете ногу каждый день по чуть-чуть (хотя даже в нем я более чем уверен, что можно обмануть компилятор и написать опасный код), а так же без необходимости держать в голове 1000 и 1 особенность работы языка и компилятора (потому что вы сами декларативно описываете поведение ваших типов и их времени жизни если речь идет о ссылках + управление мутабельностью, передачей и владением (все выдуманные категории за которыми в других языках следит компилятор, а вам приходится помнить правила того, как он на этими категориями следит)) как это например происходит в С. Так что по большей степени rust это и есть С, но вывернутый наизнанку и с альтернативным синтаксисом. Rust это С для ленивых c маленькой оперативкой мозга :3 (никого не хочу обидеть имел в виду только себя)

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

lazy_static - попытка создать глобальные переменные с вызовом процедур до main. bitflags - for sets of C-style bitmask flags. It can be used for creating typesafe wrappers around C APIs.

«Нас не устраивает раст, давайте расширим синтаксис до знакомых вещей»

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

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

abcq ()
Ответ на: комментарий от baist

Спасибо, капитан очевидность. По твоей логике и связка PHP + Haskell тоже будет смотреться очень хорошо.

Сложно понять твою логику, речь же была про бинарный код, и вдруг откуда-то «конгресс немцы какие-то» php с хаскелем.

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

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

abcq ()
Ответ на: комментарий от baist

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

С си переходить смысл вполне есть, если не в ядре или эмдебеде сидишь, раст как язык более выразителен и во многом как ни парадоксально ближе к си чем с++ (в раст нет исключений, рантайм легче чем у с++, очень легкий ооп). Вот с современного С++ смысла уже меньше, тут только из-за безопасности можно переходить.

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

Ты сам не понял что я имел ввиду. Чем сильно отличаются языки тем больше надо выполнять преобразований между ними. Как ты собрался из раста вызывать виртуальные методы C++? Писать кучу хаков и костылей? А потом в раст обратно передавать объект std::string?

Ты понимаешь что в языках разное представление данных и что передать по указателю не получится просто так если ты не знаешь как выравниваются и алоцируются данные?!

У раста есть полноценный 100% ABI везде и всюду чтоль?

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

lazy_static - попытка создать глобальные переменные с вызовом процедур до main.

lazy_static - это просто сахар. rust поддерживает глобальные переменные.

bitflags

Опять сахар.

Нас не устраивает раст, давайте расширим синтаксис до знакомых вещей

Это не делает его сишкой.

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

Ты сам не понял что я имел ввиду. Чем сильно отличаются языки тем больше надо выполнять преобразований между ними. Как ты собрался из раста вызывать виртуальные методы C++? Писать кучу хаков и костылей? А потом в раст обратно передавать объект std::string?

Речь же шла о динамической библиотеке с сишным итерефейсом, такие на и на расте и на с++ удобно как делать так и вызывать без проблем. А про вызов С++ из динамических библиотек не нужно, С++ не может и С++ вызывать в общем случае, ABI нет стандартизированного.

У раста есть полноценный 100% ABI везде и всюду чтоль?

В расте легко пользоваться сишным ABI.

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

Ты сам себе противоречишь. По твоей логике зачем писать велосипеды на расте тогда, если есть готовое на C/C++ с иcпользованием других библиотек на C/C++?! Это все равно превратиться в бинарный код в итоге. Смысл???

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

С си переходить смысл вполне есть

Так никто не хочет переходить с безопасного C#(с тем же unsafe) в том то и дело.

если не в ядре или эмдебеде сидишь

а где ниша тогда?

baist ()