On 13/10/2021 11:43, Albert Astals Cid via Development wrote:
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?
I'm not against in principle (liberal in what you accept, etc.etc.), but as you say, it's going to become a nightmare to document exactly what it's supported or not.
I'm also unsure about the practical usefulness of having "some" stuff outside a profile. Artists using Illustrator, Inkscape or similar applications cannot be expected to know exactly which SVG elements are generated and so if they're going to be OK or not. This leaves a huge grey area where things sometimes work, sometimes don't, and if they don't it's not a "bug" (Qt never claimed support for them) but a new feature.
To say the same differently: if I've got a SVG document, I can easily send it to W3C's validator and check if it's Tiny or not. If it's not, Qt is not expected to render it properly. If it is, Qt is expected to (it's a bug otherwise). If I've got a SVG Tiny+extra bits, how do I make sure that those bits are rendered correctly? I must give artists a "Qt viewer" or something like that. And if something is not rendered correctly, do I blame Qt or the artist for using something unsupported? How does the artist even know?
My 2 c, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
