Re: [Tools-discuss] [rfc-i] What do do about SVG

[Leonard Rosenthol <[e-mail]>]

I still think that a subset is the right answer – but let’s pick one that is actually in use and supported.   SVG Native - which is the subset of SVG used in SVG OpenType fonts.   More details at https://github.com/adobe/svg-native-viewer

Leonard

From: rfc-interest <[e-mail]> on behalf of HANSEN, TONY L <[e-mail]>
Date: Thursday, May 13, 2021 at 8:29 AM
To: Brian E Carpenter <[e-mail]>, Carsten Bormann <[e-mail]>, Tools Team Discussion <[e-mail]>, RFC Interest <[e-mail]>
Subject: Re: [rfc-i] [Tools-discuss] What do do about SVG
On 5/13/2021, 12:24 AM, "rfc-interest on behalf of Brian E Carpenter" <[e-mail] on behalf of [e-mail]> wrote:

    After some investigation, I've understood that this particular problem
    is because svgcheck doesn't allow <style> as a child of <svg>. Nor, after
    some experiments, as a child of <path>, even though the RelaxNG in
    RFC7996 appears to allow it. (Also, when <style> defines a color, and
    I patch svgcheck/word_properties.py to allow <style>, svgcheck doesn't
    seem to detect the color elements inside <style>.)

    In the course of this I found another instance of a particular
    bug in svgcheck (failure to increment errorCount).

    So we have the facts that
    (a) svgcheck is buggy;
    (b) it doesn't implement the RelaxNG in RFC7996;
    (c) sadly, we lost the maintainer of the code;
    (d) our subset of TinySVG is very hard to generate with most drawing tools;
    (e) experience shows that special SVG mangling programs are needed to prepare files for inclusion in RFCs;
    (f) we've been told that TinySVG is no longer alive at W3C;
    (g) browsers appear to be fully competent at interpreting full SVG.

    How can we make progress on resolving this?

As an FYI, I see three maintainers listed for svgcheck at https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fsvgcheck%2F&amp;data=04%7C01%7Clrosenth%40adobe.com%7C79979b75c21046b466a908d9160aacca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637565057435782514%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=VhSTZmdSAAtWY3War%2BQUmWbczsCwt34AX6O98yqeF1k%3D&amp;reserved=0. Can we poke them to address some of these issues, in particular a&b? Or provide them pull requests for the code?

d,e,f are somewhat intractable unless we throw it out entirely and move to full SVG. g is one argument for that.

However, there were several reasons behind going with a subset, laid out in section 2 of RFC 7996 and section 3.2 of RFC 6949. Any movement to support a larger version of SVG needs to address these requirements first.

        Tony

_______________________________________________
rfc-interest mailing list
[e-mail]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmailman%2Flistinfo%2Frfc-interest&amp;data=04%7C01%7Clrosenth%40adobe.com%7C79979b75c21046b466a908d9160aacca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637565057435792469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QYkYsiVKAv%2B9FCnMNrSBVxOopr6sKlGsMuaAlyXSznA%3D&amp;reserved=0