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

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 May 2021 18:44:50 +0200

Since this little gem didn’t seem to make it to rfc-interest, here’s a copy…
(No action needed, I solved the problem in a different way in kramdown-rfc 1.4.11.)
[I had to scale down the crisp original images for this list…]

Grüße, Carsten

On 2021-01-06, at 05:21, Martin J. Dürst <[email-masked] <mailto:[email-masked]>> wrote:
> clean SVG

Before svgcheck:

After svgcheck:

Much cleaner.  SCNR.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 May 2021 09:21:29 +1200

And this is only the latest issue. I believe from my own experiments
(which included patching the code of svgcheck, writing a supplementary
SVG massager, and manual SVG editing) that what we have simply isn't fit
for purpose. And I'm not happy about waiting for the politics of the
RFC Series Editor to be settled before we discuss what to do about
this.

[If somebody could send me the original SVG, I'd be interested to run
it through my patched tools.]

Regards
   Brian Carpenter

On 11-May-21 04:44, Carsten Bormann wrote:
> ___________________________________________________________
> Tools-discuss mailing list - [email-masked]
> This list is for discussion, not for action requests or bug reports.
> * Report datatracker and mailarchive bugs to: [email-masked]
> * Report tools.ietf.org bugs to: [email-masked]
> * Report all other bugs or issues to: [email-masked]
> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 May 2021 16:24:11 +1200

Hi,

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?

Regards
   Brian Carpenter

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 13 May 2021 12:28:31 +0000

On 5/13/2021, 12:24 AM, "rfc-interest on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

As an FYI, I see three maintainers listed for svgcheck at https://pypi.org/project/svgcheck/. 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

---

From: Leonard Rosenthol <[email-masked]>
Date: Thu, 13 May 2021 12:58:35 +0000

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 <[email-masked]> on behalf of HANSEN, TONY L <[email-masked]>
Date: Thursday, May 13, 2021 at 8:29 AM
To: Brian E Carpenter <[email-masked]>, Carsten Bormann <[email-masked]>, Tools Team Discussion <[email-masked]>, RFC Interest <[email-masked]>
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" <[email-masked] on behalf of [email-masked]> wrote:

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?

        Tony

_______________________________________________
rfc-interest mailing list
[email-masked]
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

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 14 May 2021 16:23:58 +1200

Hi Brian and Tony:

I'm the guy who wrote the original version of svgcheck.py.
Jim Schaad did the production engineering on it, and I worked with him
to make sure it was compliant with the RNC schema that appears in RFC
7996.

I recently downloaded svgcheck (from the RFC Editor site, I think),
that's version 0.6.0;  I could work through that to fix the problems
Brian reported.  However, it will need someone on the Tools team to
get the fixed version back into their repository.

Please let me know if you'd like me to make the changes to svgcheck
(it will take a week or two though).

Cheers, Nevil

On Fri, May 14, 2021 at 12:29 AM HANSEN, TONY L <[email-masked]> wrote:
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

-- 
-----------------------------------
Nevil Brownlee, Taupo, NZ

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 May 2021 16:43:00 +1200

Hi Nevil,

I'll write off list with the things I discovered. Some of it was quite
a long time ago, so I'll have to look back at my emails to Jim.

One thing for now though. I'm illiterate in RelaxNG, but it seems
to me that <style> is definitely allowed in two or three places
in RFC7996, and it isn't even defined in svgcheck/word_properties.py
so it's no wonder that svgcheck rejects it.

Regards
   Brian

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 14 May 2021 15:12:45 +0900

> 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 h…

Sounds like a good idea at first. But then I read at 
https://github.com/adobe/svg-native-viewer:

- No support for scripting, interactions, events, animations, filters, 
masks, patterns, texts.

All of these are okay except the last one. It makes sense for SVG Open 
Type (to describe glyphs in a font, text isn't needed), but it's crucial 
for drawings in RFCs.

Regards,   Martin.

---

From: Leonard Rosenthol <[email-masked]>
Date: Fri, 14 May 2021 11:24:29 +0000

Oh – good point, Martin!   Missed that one…

Leonard

From: Martin J. Dürst <[email-masked]>
Date: Friday, May 14, 2021 at 2:12 AM
To: Leonard Rosenthol <[email-masked]>, HANSEN, TONY L <[email-masked]>, Brian E Carpenter <[email-masked]>, Carsten Bormann <[email-masked]>, Tools Team Discussion <[email-masked]>, RFC Interest <[email-masked]>
Subject: Re: [rfc-i] [Tools-discuss] What do do about SVG

On 2021-05-13 21:58, Leonard Rosenthol wrote:
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fsvg-native-viewer&amp;data=04%7C01%7Clrosenth%40adobe.com%7C39a2ae849654466e56c808d9169f4e34%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637565695747863299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZynnkObNkbpKs8GtnCfnVADIT4aRWuoucX9oIQ%2FnpY%3D&amp;reserved=0
>
> Leonard

Sounds like a good idea at first. But then I read at
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadobe%2Fsvg-native-viewer&amp;data=04%7C01%7Clrosenth%40adobe.com%7C39a2ae849654466e56c808d9169f4e34%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637565695747863299%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=QZynnkObNkbpKs8GtnCfnVADIT4aRWuoucX9oIQ%2FnpY%3D&amp;reserved=0:

Regards,   Martin.

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 14 May 2021 13:10:12 +0000

Thank you, Nevil, Brian

On 5/14/2021, 12:43 AM, "Brian E Carpenter" <[email-masked]> wrote:

    Hi Nevil,

    Regards
       Brian

    On 14-May-21 16:23, Nevil Brownlee wrote:
    >> As an FYI, I see three maintainers listed for svgcheck at https://urldefense.com/v3/__https://pypi.org/project/svgcheck/__;!!BhdT!3hOxHzMKjodMzADvfA9H8y70wYlv3lgGYPIoeh7v2-GPsHPlZ0GobwwsCQ$ . Can we poke them to address some of these issues, in particular a&b? Or provide them pull requests for the code?
    >>
    >> https://urldefense.com/v3/__https://www.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!3hOxHzMKjodMzADvfA9H8y70wYlv3lgGYPIoeh7v2-GPsHPlZ0GOjT-1tQ$ 
    > 
    > 
    >

---

From: Robert Sparks <[email-masked]>
Date: Fri, 14 May 2021 08:52:05 -0500

The repository for svcheck is at 
https://github.com/ietf-tools/RfcEditor/tree/master/svgcheck.

RjS

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 May 2021 11:21:48 -0400

On Thu, May 13, 2021 at 8:28 AM HANSEN, TONY L <[email-masked]> wrote:

> On 5/13/2021, 12:24 AM, "rfc-interest on behalf of Brian E Carpenter" <
> [email-masked] on behalf of
> [email-masked]> wrote:
>
> As an FYI, I see three maintainers listed for svgcheck at
> https://pypi.org/project/svgcheck/. Can we poke them to address some of
> these issues, in particular a&b? Or provide them pull requests for the code?
>
> 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.
>

I pointed out these issues over three years ago. This group has shown zero
interest in making any change. So no,  three more years of arguing over
which subset to pick is not an acceptable approach. I suggest:

1) Pick a deadline for making a decision. No more than six months.
2) Begin with the standard SVG and only eliminate what is absolutely
necessary to remove.
3) Make conformance with popular commercial drawing tools a requirement.
4) Consider the checker to be a support tool rather than an enforcement
mechanism. It is really not that difficult breaking out of the sandbox of
the current tools.

Alternatively, since W3C face the same need with respect to scripting in
documents as we do, perhaps we should just ask them what they do in this
regard. Dave Ragget's tiny was used to strip down HTML at one point, I bet
they have the same for SVG.

W3C has vastly more expertise in document formats than we do in IETF or
could ever hope to have. HTML and SVG were explicitly designed with
archival considerations in mind. Trillions of documents in these formats
exist. They are at this point just as established as ASCII or UNICODE as a
permanent infrastructure. If humanity loses the knowledge of how to
interpret HTML+SVG docs, it has probably forgotten how to interpret binary
data.

If people do want a custom approach, the way to go about it is to start
with the SVG DTD and remove elements. Checking an image is then merely a
matter of applying the modified DTD. RelaxNG has its place but that place
is not enforcing restrictions on a specification written in another schema
language.