Subject: Re: [xml2rfc-dev] SVG broken (Re: New xml2rfc release: v2.45.0)

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 1 Jun 2020 14:03:26 +0200

Hi Carsten,

On 2020-05-29 23:29, Carsten Bormann wrote:
> On 2020-05-29, at 21:56, Carsten Bormann <[email-masked]> wrote:
>> 
>> I no longer get SVG through this version that has been “repaired” by svgcheck -qra; the SVG processing now seems very picky.  (I haven’t updated since 2.39, so this might have happened earlier.)
> 
> Well, OK, this is now SVG generated by ditaa instead of goat, and ditaa seems to want to show of its knowledge of SVG some more.  So that may not be a change in xml2rfc at all.  My question is mostly still valid, though:
> 
>> Is svgcheck still intended to be the tool to be used with xml2rfc to make SVG palatable to it?  Is that being updated along with xml2rfc ...?

In principle yes, but there has been no change in the acceptable SVG schema,
and thus no change in xml2rfc and svgcheck in this regard for a long time now.

Author of svgcheck is Jim Schaad, he may be able to say more about the
expected usage of the tool.

	Henrik

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Jun 2020 16:22:38 +0200

Hi Henrik,

> and thus no change in xml2rfc and svgcheck in this regard for a long time now.

Thank you.

So my summary of the current situation would be that there are a few mismatches between the two, each of which could be limitations in either svgcheck’s repair feature or in xml2rfc.

> expected usage of the tool.

Right.  So when I see some of these mismatches, I would need to consult RFC 7996 and find out which of the two has a bug/limitation before I can log this as an issue.

Since this is on the XML2RFC lists, let me mention it would first of all help if the error messages were more easy to process, e.g.:

y2020-05-29svg.xml(645): Error: Invalid attribute stroke for element text, at /rfc/middle/section[2]/section[2]/artset[2]/artwork[1]/*/*[2]/*[7]
y2020-05-29svg.xml(666): Error: Invalid attribute stroke for element path, at /rfc/middle/section[2]/section[2]/artset[3]/artwork[1]/*/*[2]/*[4]

These do not lead me to what might the problem (in RFC 7996, stroke is actually allowed both for text and path).
It seems that these messages are about the attribute value instead, which I can look up in the source line given; it would be more useful if the attribute value were given, plus maybe some indication of what is “invalid” about it.
For instance, xml2rfc rightly does not seem to accept stroke=“none”, which is let through by svgcheck.
Also, I had to replace some stroke=“#000000” by stroke=“black”, which RFC7996 tells me should not have been necessary, but I can’t see what the problem really was from the above.

Here are the fixes my code is currently applying:

XPath.each(d.root, "//*[@shape-rendering]") { |x| x.attributes["shape-rendering"] = nil }
XPath.each(d.root, "//*[@text-rendering]") { |x| x.attributes["text-rendering"] = nil }

These should be allowed on the svg element, but apparently aren’t; again, the error message does not tell me what’s going on:

y2020-05-29svg.xml(606): Error: Invalid attribute shape-rendering for element svg, at /rfc/middle/section[2]/section[2]/artset[1]/artwork[1]/*

XPath.each(d.root, "//*[@stroke]") { |x| x.attributes["stroke"] = svg_munch_color(x.attributes["stroke"], false) }
XPath.each(d.root, "//*[@fill]") { |x| x.attributes["fill"] = svg_munch_color(x.attributes["fill"], true) }

svg_munch_color tries to map everything to “black” or “white”; RFC 7996 actually allows other values.  This code also gets rid of “none”-valued attributes completely for stroke (but not for fill!), which seems to be an oversight in svgcheck.

Grüße, Carsten