[Development] Implementing small SVG 1.1 features (as opposed to SVG Tiny 1.2)
Aleix Pol
aleixpol at kde.org
Thu Oct 14 04:15:39 CEST 2021
On Wed, Oct 13, 2021 at 11:44 AM Albert Astals Cid via Development
<development at qt-project.org> wrote:
>
> Hello,
>
> I understand that the current QtSVG support is clearly stated to be SVG Tiny
> 1.2
>
> We have some clients that would like to add some rendering features from the
> non Tiny variant.
>
> For example supporting x,y attributes in tspan. This would help fixing the
> rendering of the attached SVG (compare inkscape where it's vertical text vs
> QtSVG where it's not).
>
> Implementing support for this doesn't seem like it should be "super hard"
> (famous last words) and would help rendering some SVG files that are out there
> in the wild.
>
> I know this would be confusing as to being able to document exactly what QtSVG
> supports, but it seems to me that if we allow bit by bit small improvements we
> could eventually end up with more of the SVG specification supported, since it
> seems unlikely that someone will have the time to work on a "mega merge
> request" which implements all of the specification.
>
> What do you think?
>
> Should we allow some small features outside of the declared SVG Tiny 1.2
> support?
>
> Best Regards,
> Albert
>
> --
> Albert Astals Cid | albert.astals.cid at kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts_______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
I'd say it's clearly needed, at least from our side. We even have
someone pitching the use of librsvg instead.
https://invent.kde.org/frameworks/kiconthemes/-/merge_requests/1
IMHO, incremental changes make sense if the alternative is no changes. :)
We can always claim to only do properly SVG Tiny and only announce the
next standard supported whenever we are compliant with it. Currently
we render everything tiny or not, we only render some of them wrong.
Aleix
More information about the Development
mailing list