resvg

Matthias Klumpp matthias at tenstral.net
Fri Mar 15 04:53:31 GMT 2024


Am Fr., 15. März 2024 um 05:38 Uhr schrieb Страшила <igor.mironchik at gmail.com>:
> пт, 15 мар. 2024 г., 00:51 Laura David Hurka <david.hurka at mailbox.org>:
>>
>> On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote:
>> > On 2024-03-14, Igor Mironchik <igor.mironchik at gmail.com> wrote:
>> > > Hello,
>> > >
>> > > What do you think about https://github.com/RazrFalcon/resvg in case of
>> > > processing and rendering SVGs?
>> > >
>> > > Do you have any plans to have this in Craft?
>> >
>> > With the current revitalization of QtSvg, I kind of think we should work
>> > harder with that rather than try to replace it.
>> > It is after all hooked in quite deep in our stuff already, so most of
>> > our svg's needs to be compatible with QtSvg anyways.
>> >
>> > /Sune
>>
>> Well, QtSvg can only render (and create) SVGs, but there is no way to process
>> an SVG document in a different way than to render it on a paint device.
>> For me, this is a good reason to be interested in resvg.
>
>
> By processing meant reading and parsing of XML/SVG.

One thing I always wonder with these Rust projects, and resvg in
particular, is future maintainability.
Just to make resvg, its developer reimplemented:
* Parts of the Skia graphics library in Rust (as tiny-skia)
* Parts of the Harfbuzz text shaping engine algorithms in Rust (rustybuzz)
* An entirely new XMl parsing library
* A new CSS parser
* A CLI arguments parser
* An in-memory font database

I am all for trying new things, but these rewrite-the-world projects
have to be maintained somehow in the very long-term, most likely
alongside the original projects. And there's only a finite amount of
developers.
Meanwhile QtSVG is built on top of Qt, which uses the regular Harfbuzz
and Qt for drawing.

For sure having dependencies on rewrites of existing projects
absolutely does not rule out their use, but before depending on
something this fundamental, I would love to see the project and its
rewritten dependencies show that they are actively and long-term
maintained (which looks excellent for resvg, but a bit less so for its
dependencies).

Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


More information about the kde-devel mailing list