Am Fr., 15. März 2024 um 05:38 Uhr schrieb Страшила <igor.mironc...@gmail.com>: > пт, 15 мар. 2024 г., 00:51 Laura David Hurka <david.hu...@mailbox.org>: >> >> On Thursday, March 14, 2024 2:04:45 PM CET Sune Vuorela wrote: >> > On 2024-03-14, Igor Mironchik <igor.mironc...@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/