Hi all, Best wishes for 2022.
Recently Joris and Darcy made changes in the handling of SVG images : they are now entirely managed by Qt, which seems a nice and consistent move. However, if a user tries for instance to insert https://commons.wikimedia.org/wiki/File:Subduction-en.svg (a valid svg file as per W3C), they will find a barely recognizable image and probably blame TeXmacs for that. This is not an isolated issue; most of my images produced with Inkscape also have rendering issues with Qt, although they look perfect in web browsers. The main reason for these problems is that Qt only supports the restrictive specification SVG 1.2 Tiny, while browsers support SVG 1.1 Full, although it is far from obvious in Qt documentation (to have an idea of the differences see https://en.wikipedia.org/wiki/Comparison_of_layout_engines_(Scalable_Vector_Graphics)#SVG_1.1_support). Beyond this limitation, there are also a lot of open Qt bugs around SVG (QTBUG-96013, 95193, 96013, 44863, 94326, 90803, 42196, 87712, 87327, 88494, 25896 (open since 2012!) , 73776, 72997, 69508, 27611 ...). Note also that in QTBUG-87327 I found the comment "Currently the SVG component is unmaintained" (Oct 2020) and looking at the commits at https://github.com/qt/qtsvg/graphs/contributors confirmed that. So, sadly, SVG in Qt is a mess that will not resolve anytime soon. For improving the situation I suggest TeXmacs has the following behavior : - When an external converter is available (Inkscape or rsvg-convert), use it unconditionally for all svg images (converting them to bitmap for screen display or pdf for printing). - If no converter is available, when inserting/displaying an SVG image, check the svg version, and if it is not 1.2 Tiny, display a message to the user advising them to convert the image to pdf, or to install a converter. Philippe _______________________________________________ Texmacs-dev mailing list Texmacs-dev@gnu.org https://lists.gnu.org/mailman/listinfo/texmacs-dev
