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

Carsten Bormann <cabo@tzi.org> Mon, 01 June 2020 14:22 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: rfc-markdown@ietfa.amsl.com
Delivered-To: rfc-markdown@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFEF3A10BA; Mon, 1 Jun 2020 07:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR0yXMSiLS6W; Mon, 1 Jun 2020 07:22:46 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33B63A10B9; Mon, 1 Jun 2020 07:22:44 -0700 (PDT)
Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49bHSf2P8Lzyqr; Mon, 1 Jun 2020 16:22:42 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <109c4ce5-82a6-3651-69ae-8f9950484412@levkowetz.com>
Date: Mon, 1 Jun 2020 16:22:38 +0200
Cc: rfc-markdown@ietf.org, XML2RFC Interest Group <xml2rfc@ietf.org>, xml2rfc-dev@ietf.org
X-Mao-Original-Outgoing-Id: 612714158.577495-705881f09acac57eb92d290ee5a656cf
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A04D45E-33C8-4965-A9AB-FF52909F29F9@tzi.org>
References: <E1jduEw-0007if-7I@durif.tools.ietf.org> <93E5295E-CE96-4121-B3F5-C04540D542FD@tzi.org> <D6806E5D-2B6E-4464-9126-44F3F5C808F7@tzi.org> <109c4ce5-82a6-3651-69ae-8f9950484412@levkowetz.com>
To: Henrik Levkowetz <henrik@levkowetz.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfc-markdown/oGaVRmkpVqoK5ls0xL-Lj5LeR5I>
Subject: Re: [Rfc-markdown] SVG broken (Re: [xml2rfc-dev] New xml2rfc release: v2.45.0)
X-BeenThere: rfc-markdown@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "rfc-markdown is a discussion list for people writing I-Ds and RFCs in Markdown and the authors of the tools used for that." <rfc-markdown.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfc-markdown/>
List-Post: <mailto:rfc-markdown@ietf.org>
List-Help: <mailto:rfc-markdown-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfc-markdown>, <mailto:rfc-markdown-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2020 14:22:49 -0000

Hi Henrik,

>>> 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.

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.

> Author of svgcheck is Jim Schaad, he may be able to say more about the
> 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