Subject: [rfc-i] What do do about SVG

From: "John R. Levine" <[email-masked]>
Date: 15 Dec 2020 14:47:22 -0500

> I'd like to see some constructive discussion of how to fix the SVG
> problem. Of course, that would need to start with an analysis of
> what the problem is, beyond that fact that generating diagrams that
> respect the current rules is a major pain.

Yeah, that's on the list.  Not being much of an SVG user I gather that we 
backed the wrong horse and picked an SVG profile that nobody else uses.

Assuming that one of the goals is to have good tool support, what SVG 
tools do people use and what profiles do they support?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Dec 2020 15:32:26 -0600

> tools do people use and what profiles do they support? 

I haven't looked into the second half of the question, but for me, if I 
were generating SVG diagrams, I would use either Omni Graffle or Inkscape.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Dec 2020 11:51:04 +1300

On 16-Dec-20 08:47, John R. Levine wrote:
...
> tools do people use and what profiles do they support?

Yes, indeed the problem is that people need to use a drawing tool
and as far as I can see, none of the drawing tools I've tried
support a TinySVG profile, let alone the RFC7996 subset of it.

I have used (at least) the following:
LibreOffice
dia
a web site for drawing Venn diagrams (http://bioinformatics.psb.ugent.be/webtools/Venn/)

and fed the results through svgcheck and some additional hacks
of my own, plus manual editing of the SVG file (which is of
course just a dialect of XML).

The kind of problems that I've encountered are that even if you
manage to avoid colour or greyscale, lots of other things that
are disallowed by RFC7996 show up and svgcheck cannot fix them.
Yet the SVG can be rendered by every browser I've tried. So while
we have good reasons for some restrictions, I don't think we
get anything but hassle from the TinySVG restrictions.

Restrictions we do need, IMHO, include
- no colour
- no greyscale
- no scripting
- no external URLs
- use viewbox and *no* height/width, to allow proper scaling

but we shouldn't waste everybody's time by worrying about
SVG syntax in general.

(If there was some SVG equivalent of PDF-A, that would be
fine, but there isn't, to my knowledge.)

    Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Dec 2020 19:54:40 -0500

> - use viewbox and *no* height/width, to allow proper scaling

ISTM that the "no colour" and "no greyscale" are only there in lieu of 
the unstated requirement:

    Only allow drawings that can be also be drawn using text
    graphics while retaining the key information content.

Otherwise I don't see now they are justified. Am I missing something?

	Thanks,
	Paul

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Dec 2020 20:08:41 -0500

There are a whole host of issues that were raised.  The agreement was to 
get simple graphics first, and then work on the othe rissues.

For example, if one allows color, how does one ensure readability by 
those who are color blind.
Similarly, if one allows gray scale, how does one make sure the result 
is understandable to those who do not perceived detailed contrast 
differences as easily.

And scripting is a nightmare all its own.

Some issues are easier.  For example, external URLs simply fail the test 
for archival representation.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Dec 2020 14:27:51 +1300

> is understandable to those who do not perceived detailed contrast 

Both of which are made worse by an assumed requirement to be able to
use a monochrome printer, where colours may not be distinguishable
and pale hues may be invisible.  (Speaking purely for myself, I
really resent the price gouging for coloured inks.)

   Brian

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Dec 2020 22:53:37 -0600

It is increasingly sounding like we got ourselves in this pickle by 
coming up with some reasonable policy decisions (no greyscale, no 
animations, no scripts, no external references), and then decided to use 
a technical enforcement mechanism by way of an SVG profile.

Perhaps rather than using syntax to enforce policy, we could shift to 
using editorial control to enforce policy. That is, we specify that 
non-ASCII diagrams in RFCs are in full-fledged SVG, which has really, 
*really* good support in a lot of tools. And then put have in place 
instructions to the authors and to the RPC that describe the policy 
restrictions (such as those I list above), along with a tool -- in the 
style of id-nits -- that helps identify (in an advisory way) when those 
policies might not have been followed.

/a

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 16 Dec 2020 18:15:26 +1100

> policies might not have been followed.

I think that is entirely sensible.

I will note that your requirements permit the inclusion of raster images as data: URIs.  Those might be hard to detect without tools.  We'll likely need a little back and forth on what the true requirements are.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Dec 2020 12:07:47 +0100

Am 15.12.2020 um 20:47 schrieb John R. Levine:
> Yeah, that's on the list.  Not being much of an SVG user I gather that
> we backed the wrong horse and picked an SVG profile that nobody else uses.
>

I have tried to use Graphviz' SVG output, also KGT railroad diagrams.

In both cases, even after using a tool to strip colors etc (see
<https://github.com/reschke/xml2rfc/blob/master/prep-xml2rfc.xslt>), the
lack of markers made things really hard.

Best regards, Julian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Dec 2020 08:16:32 -0500

Martin Thomson <[email-masked]> wrote:
    >> style of id-nits -- that helps identify (in an advisory way) when
    >> those policies might not have been followed.

    > I think that is entirely sensible.

I also agree.
This doesn't excuse us from getting authoring tools fixed.
Perhaps some tools will be willing to have a save-as profile.
I still need to know what I did wrong in my content.
Why just us? maybe others in the printing industry will care too.

We are gonna need a way better idnits tool, but I believe that the LLC tools
cmte knows this already.  I hope they are planning to redo idnits soon.

    > I will note that your requirements permit the inclusion of raster
    > images as data: URIs.  Those might be hard to detect without tools.
    > We'll likely need a little back and forth on what the true requirements
    > are.

you mean like the data: URI ?
I'm sure that was unintentional, but yeah, we'll need a tool.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael StJohns <[email-masked]>
Date: Wed, 16 Dec 2020 14:07:36 -0500

> those policies might not have been followed.

I think this is an interesting idea that misses at least one point of 
the SVG profile.  E.g.  Your tool might be able to produce SVG that the 
RPC's tools might not be able to render.

Before we head off in this direction, perhaps someone can do a table 
that has the tools proposed for authoring on one axis, and the tools 
proposed for rendering on the second axis (could be the same group) and 
see if the export from one will work as an import for the other.

Later, Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Dec 2020 17:02:28 -0500

Michael StJohns <[email-masked]> wrote:
    >> Perhaps rather than using syntax to enforce policy, we could shift to using
    >> editorial control to enforce policy. That is, we specify that non-ASCII
    >> diagrams in RFCs are in full-fledged SVG, which has really, *really* good
    >> support in a lot of tools. And then put have in place instructions to the
    >> authors and to the RPC that describe the policy restrictions (such as those
    >> I list above), along with a tool -- in the style of id-nits -- that helps
    >> identify (in an advisory way) when those policies might not have been
    >> followed.

    > I think this is an interesting idea that misses at least one point of the SVG
    > profile.  E.g.  Your tool might be able to produce SVG that the RPC's tools
    > might not be able to render.

    > Before we head off in this direction, perhaps someone can do a table that has
    > the tools proposed for authoring on one axis, and the tools proposed for
    > rendering on the second axis (could be the same group) and see if the export
    > from one will work as an import for the other.

To first order, the "rendering" will be browsers, and we have pretty good
interoperability there.

The problem is that the second order group is black and white printers
printing paper which will be viewed by people with various amounts of
differentially abled vision.

The archival goals of our series say that we need to accomodate the second
order group.

So you are right that we need to match tools to "viewers", but our problem is
that the viewers in the second group are difficult to simulate today.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Dec 2020 23:48:55 +0100

On 2020-12-15, at 20:47, John R. Levine <[email-masked]> wrote:
> 
> Assuming that one of the goals is to have good tool support, what SVG tools do people use and what profiles do they support?

Assuming that we talk about authoring tools:

Inkscape and Omnigraffle were mentioned as the tools many people use for interactively creating graphics, maybe add Affinity Designer and Adobe Illustrator.  (All these also have some import function, although that is sometimes a bit of a hit or miss, as the internal data model may not be very congruent with all the complexities of SVG.)

There are also often import routes via EPS and PDF, pdf2svg/pdftocairo may be a general import mechanism for graphical information available in PDF form, which may in turn be generated by a zillion tools such as pandoc.

There are also tools that convert (potentially non-graphical) source-type information into graphics, which often support SVG output:

* goat and ditaa (for ASCII^Wtypewriter-art)
* mscgen (for message sequence charts)
* mermaid (for Flowchart, Sequence diagram, Class Diagram, State Diagram, Entity Relationship Diagram, User Journey, Gantt Chart, Pie Chart)
* plantuml (for UML diagrams, including much of the above)
* tex2svg (math formulae; can also use e.g. pandoc/pdftocairo)
* graphviz (general diagrams; DOT language, with neato, lefty)

Some of these tools assume they can use at least one gray scale level/color different from black/white; it is nearly impossible to compress this to bi-level (well, yeah, you can always use hatching or halftoning, for unwieldy and excruciatingly slow documents).

Graphs are also generated programmatically, e.g. using matplotlib or gnuplot.
Packages such as R have multiple SVG interfaces (e.g., svelte).

Note that not all of these have already been used for an RFC or I-D today, but this is like saying not all editors have been used for typing markdown — eventually, they will.  Use the right tool for the job.

Authors would probably do most of their rendering in browsers.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Dec 2020 14:11:10 +1300

> To first order, the "rendering" will be browsers, and we have pretty good

Yes. While Mike is correct in principle, I think that rendering will not
be a problem in practice, simply because browsers have to render whatever
is out there in the real world anyway.

(Note however that "Save as SVG" is definitely not guaranteed to
save the same SVG as the rendering tool loaded. SVG -> screen -> SVG
is very likely to change the SVG slightly.)

> differentially abled vision.

Yes, hence the ban on colour and greyscale.

   Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Dec 2020 12:55:00 +1100

> is out there in the real world anyway.

This is a great question still.  Mike's response gave me pause, but only because it raised the question of what it means for these to be of "archival" quality, and whether that even makes sense.  In that regard, a JPG has better prospects; SVG is not static, it continues to evolve.

However, I think that Adam and Brian's pragmatism is what we should look to for an answer.  Our editorial guidance already ensures that comprehension of diagrams is not absolutely necessary to the understanding of the document.  And many cases will have ASCII art fallbacks.  That means our SVG dependency is very much opportunistic.

Pragmatism suggests we just apply a little diligence and not expend too much effort following the path of RFC 7996, now that we know that to have failed to produce a good outcome.  It was a fine experiment, but it did not turn out to be practical.

That is, we test that the image loads consistently in a reasonable sample of implementations and then have some tools to catch known problems.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Dec 2020 22:40:16 +0100

[Routing around an email server problem via gmail]

Grüße, Carsten

---

From: Leonard Rosenthol <[email-masked]>
Date: Sun, 20 Dec 2020 15:43:13 +0000

> JPG has better prospects; SVG is not static, it continues to evolve
>
Actually the JPEG committee is much more active that the SVG committee - and I serve on both.

JPEG-1 (what most folks just refer to as JPEG) already has a number of backward-compatible(-ish) extensions to it (JPEG-XT, JPEG360, etc) with more in development.  The various committees meet at least once or twice a month.

SVG on the other hand dropped SVG 2.0 and is pretty much dormant waiting to see what sorts of functionality is desired by browsers (since they set the direction rather than actual users ☹ ).

Leonard

On 12/16/20, 8:55 PM, "rfc-interest on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    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%7C4a6a2b15397a4f193b8908d8a22ed226%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637437669282982073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2BxdgUfdksLxhhvb2S2MO5lL0WmXkQTUX9RqrkiqI6M8%3D&amp;reserved=0