Re: [rfc-i] No, constraining to a custom SVG profile is not trivial

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 23 January 2020 04:24 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 15DB7F406F4 for <rfc-interest@rfc-editor.org>; Wed, 22 Jan 2020 20:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFY07J206F27 for <rfc-interest@rfc-editor.org>; Wed, 22 Jan 2020 20:24:07 -0800 (PST)
Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) by rfc-editor.org (Postfix) with ESMTPS id DCB38F406F0 for <rfc-interest@rfc-editor.org>; Wed, 22 Jan 2020 20:24:06 -0800 (PST)
Received: by mail-oi1-f176.google.com with SMTP id 13so1665641oij.13 for <rfc-interest@rfc-editor.org>; Wed, 22 Jan 2020 20:24:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GOAG9QP7A2yzi3wLJzxEAGToX39NEAGysc4aaqorBuU=; b=bAp2jU6xeCbQ9yhU/4dOvhwDAeOingbw6GCSiEluhJUP1/LYJ9/r668tMaOnXZQD66 JMxiLTevcbFA08rMu+iE9vOnwrNllg4HExZ7H/fr3Rx9jLsZNEt6vKODsS9EvwtUuny0 AjbFQW+qCtFPOQFESLXZ23zHyePym3Z+WlK1u0Jy8oM5FXE8bA80y4Wla4Kqbc5UAkLy SV8cH0i/Kisc6Zt9ocPZxe/QwhcRbALsLo+DPGSm+p32xcvCvDpOnlvXp++J6RQA7CQq iXbOhM9hXxfOf9Af+VyZjMm9u/oBYrwFAV/k9++2tRHBQpipm9ileuiof2e9TxpaRRCv PRrA==
X-Gm-Message-State: APjAAAXxEyULfVmwCr9a4YZAPyE0Jz4qH+FshRDqzySdDPiM8/4iwl92 Qe6da9I0FcCawQFVNucUm5cIePTAOi0IR6vZgaE=
X-Google-Smtp-Source: APXvYqwYmE+4FILXl+pSK8Cmv8xKoqFZ4xgFUjDt6dhC0din4bLzt7Zfrx5b9M/qcpawfghlY+cFHhWjIcZ0ZqLLSg0=
X-Received: by 2002:a54:4f04:: with SMTP id e4mr8859776oiy.111.1579753455830; Wed, 22 Jan 2020 20:24:15 -0800 (PST)
MIME-Version: 1.0
References: <CAMm+LwiXhhJO7qYi41+DC4W7uMUVipXqyq75Fq2vagA1ppJNdA@mail.gmail.com> <10cca93f-a8b8-4c42-0653-3b12fa67ad12@gmail.com> <CAMm+LwgA-1UffBfrH-Y3J6pfh7ni9kNrndp=gHNyUyi5j=oLxg@mail.gmail.com> <53607da4-6608-783b-b875-65551e3add19@gmail.com> <CAMm+LwgNU2Dr3bB+A8k+UwbQiRRzgUkoRRh60tc6+bBv6CXwfQ@mail.gmail.com> <70ed6362-41ee-faf5-8f90-d094455dbdf4@gmail.com> <CAMm+Lwhy-AV_K5evzGdpDi-ynpLE4RxXCVB1HercickYfZaubg@mail.gmail.com> <27103.1579626232@localhost> <31cf835c-aad6-637f-fc12-8f3efa04e6e7@gmail.com> <4BEFDBE7-6D0E-46E2-BDC5-31D0121400C0@akamai.com> <CAF4+nEFHfErPYQO2u9G8x0cu3_0XexgEwit0=KmXPbc2yBavSw@mail.gmail.com> <9181ffd5-c8a9-24ad-4024-18da52f2cd4e@gmail.com>
In-Reply-To: <9181ffd5-c8a9-24ad-4024-18da52f2cd4e@gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 22 Jan 2020 23:24:04 -0500
Message-ID: <CAMm+LwjMSy1Pk1pVvkBpVt5A6B2fYeMyQ4D3bdQWreKFt-C+6w@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Donald Eastlake <d3e3e3@gmail.com>, RFC Interest <rfc-interest@rfc-editor.org>
Content-Type: multipart/alternative; boundary="000000000000914da0059cc703ae"
Subject: Re: [rfc-i] No, constraining to a custom SVG profile is not trivial
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 04:24:08 -0000

(For some reason the last posts only just showed up or would have answered
them all in one.)

On Wed, Jan 22, 2020 at 9:29 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 23-Jan-20 11:29, Donald Eastlake wrote:
> > There does exist a system form mapping some colors into cross
> > hatchings. See hatchings at
> > https://en.wikipedia.org/wiki/Tincture_(heraldry).
>
> However, I think that realistically we can't expect IETF tooling to
> perform that complex a remapping (colour to cross-hatching). It really
> would need to be done with the initial drawing tool.
>

Not necessarily.

It would certainly be horrible if you are trying to use perl scripting or
SLT. But I have what amounts to the SVG DOM. So it is actually not that
difficult to implement that type of processing or the processing or some of
the features suggested earlier.

The main part of the tool is only 700 lines of code:

https://github.com/hallambaker/PHB-Build-Tools/blob/master/DocTools/Goedel.Document.RFCSVG/Program.cs

The method Attribute at line 268 is currently substituting x/y attributes
for dx/dy which requires the font size etc to be tracked.

The same approach could easily be used to vet color values for contrast. My
original diagrams use color but in a very limited fashion. Most have two
colours plus black and white.



> gnuplot, for example, supports setting monochrome linetypes when plotting
> multiple variables on a single graph. LibreOffice Draw supports
> cross-hatching. Unfortunately the SVG that it generates includes a
> construct (<path style="fill:url(#pattern1)"  .../>) that we apparently
> don't allow, even though it's an internal reference:
>

I don't currently support that transformation, what my tool would produce
instead is:

<path fill="url(#pattern1)"  .../>

I can easily write an FSM to resolve this, the reason I didn't is that the
features that use url() aren't in SVG-Tiny.

Anyone wanting to use SVG diagrams in an RFC is going to need a tool that
can do the deep parse if they are going to use more than one diagram
because they will both have an id="pattern1" element.