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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 24 January 2020 21:53 UTC

Return-Path: <brian.e.carpenter@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 91797F40724 for <rfc-interest@rfc-editor.org>; Fri, 24 Jan 2020 13:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jik7fx5SSMJd for <rfc-interest@rfc-editor.org>; Fri, 24 Jan 2020 13:53:26 -0800 (PST)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) by rfc-editor.org (Postfix) with ESMTPS id 1239AF40723 for <rfc-interest@rfc-editor.org>; Fri, 24 Jan 2020 13:53:26 -0800 (PST)
Received: by mail-pf1-x441.google.com with SMTP id x185so1747164pfc.5 for <rfc-interest@rfc-editor.org>; Fri, 24 Jan 2020 13:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2XzKnb1TAGrZ5YXjweVyv0u9hty5rCcOWwYL+zqP0B0=; b=UZkQlNAwkyXYULyd+0VVjfNgiykQsxhnoSot66EqAwHR1OtNdF3f4+P28kqfrCAY+r kSyuVRKODzfjZT5qXUAQtw98flxedGOZ5HVGlE0Bl+dTQsWLwqZddE00tfBt6W1vLise VyPmZR0QHRq+XkIlrLYOyQS3sqC3eC2+m6ErlE9bCukaFIo75zujnGdZbrltCxuuwyXq s8OeoACtN4ty7w+skOjUf7Pye+kG2LhoC7WPw49HXLCFAUhB+kkNKjOgUvQFASiNAHto l/sQA/TWYKkYIjfalNpqXWVpLy8rJFNsDj6+Z+AoJLlKx8LL4p9lYOY9uohcQ4fuh96b AIxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2XzKnb1TAGrZ5YXjweVyv0u9hty5rCcOWwYL+zqP0B0=; b=YeEAyr7DbmbRV0mUuWCy5PJIDnPSObahbhDvQvH6GBl/JE00JMsKhb5G5Xk4/TjTAA DvNEa6gwmVqS07iU/CZuI3AjNiFIU8z54X1UbI5F2REtUGC07pSUKZzI4+j7ltPsCsHe EBF/6CYC95aF3XHElxmh+VOA+96mY9jBYBncp0g42fFocZJJUFONDP/SMsbSB3XB2hHZ LFVYLrxjpD2C8KMfGNFcRecUaISPTiH7txBrehU6UMLrJFL8DCzA4yripiV8Xlwutzty /gnCHGq9rdxO6N+c5HMWxxw8b6D5bdc+1KKq9qgNEtnv/Vv4Lq1mDtZvlVSTd/MMEjad baQg==
X-Gm-Message-State: APjAAAWiicYjNBzh+kv3NDoMGecvJ3BQuYc6AQR0dkYWqub2bSLb/+9m 5h8F8Ju0boqmDkOWXihyR1XK6SyC
X-Google-Smtp-Source: APXvYqxumS+MU2fN57xV1/lriOa9P2irJA3fPnTCf6HyWsCb2pG76/6LFp1de5CXFTcDbfVPDaO9pg==
X-Received: by 2002:a63:c207:: with SMTP id b7mr6479744pgd.422.1579902816060; Fri, 24 Jan 2020 13:53:36 -0800 (PST)
Received: from [192.168.178.30] (88.161.69.111.dynamic.snap.net.nz. [111.69.161.88]) by smtp.gmail.com with ESMTPSA id s22sm7025784pji.30.2020.01.24.13.53.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jan 2020 13:53:35 -0800 (PST)
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Donald Eastlake <d3e3e3@gmail.com>, RFC Interest <rfc-interest@rfc-editor.org>
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> <CAMm+LwjMSy1Pk1pVvkBpVt5A6B2fYeMyQ4D3bdQWreKFt-C+6w@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <aabb9253-800e-998d-824f-5a7a85ff9bff@gmail.com>
Date: Sat, 25 Jan 2020 10:49:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAMm+LwjMSy1Pk1pVvkBpVt5A6B2fYeMyQ4D3bdQWreKFt-C+6w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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: Fri, 24 Jan 2020 21:53:28 -0000

<snip>

>>     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)"  .../>
That is also rejected by unpatched svgcheck. Not that this matters when a common drawing tool like LibreOffice generates the other form. That's really the problem here: using a widely available tool and sticking to the IETF intention (such as cross-hatching instead of colour) doesn't guarantee conformance. That is unsaleable even to the specialised market of RFC authors.

Regards
   Brian

On 23-Jan-20 17:24, Phillip Hallam-Baker wrote:
> (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 <mailto: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.