Subject: [rfc-i] What do we want in SVG

From: "John R. Levine" <[email-masked]>
Date: 11 Oct 2021 22:04:05 -0400

The discussion about unreadable text reminds me that I think we all agree 
that the SVG Tiny 1.2 subset described in RFC 7996 does not match either 
what tools do or what we want to include in diagrams very well, but it's 
not clear what would be better.

I do not claim to be a great SVG expert but it is my impression that SVG 
Tiny 1.2 is little used and poorly supported, but SVG 2 has no comparable 
subset.

I also note this draft which is for the BIMI WG.  Its intended use is 
different, logos to display in the list of messages in a mailbox but it 
shares the goals of being simple and compact.

https://datatracker.ietf.org/doc/html/draft-svg-tiny-ps-abrotman-00.html

Where should we go from here?  I don't think it would be a good idea for 
us to define yet another SVG subset that no tools will support.  Could we 
work in the other direction, a common subset that existing tools can 
produce?

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: "Martin Thomson" <[email-masked]>
Date: Tue, 12 Oct 2021 14:18:17 +1100

> work in the other direction, a common subset that existing tools can 

I don't think that this is something that we can manage with tools.  In practice, SVG offers authoring tools a great deal of flexibility, which they each exercise in different ways according to their own constraints.  We could standardize on a small set of tools and deny people flexibility in how they author documents or we could accept that diversity and attempt to constrain it.

I've come to realize that hard technical constraints are increasingly intractable.  Constraints will be violated for spurious reasons, deny tools the option of using a feature that is perfectly reasonable (markers for arrow heads, say).  Also, constraints will fail to catch real problems, like the ones that goat produced in RFC 8899.

Take the following document:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 6.2891302 7.5190253" height="7.5190253mm" width="6.2891302mm">
  <path d="M 4.710355,5.7645411 Q 4.1935923,6.2037894 3.713003,6.3846563 3.2375813,6.5655232 2.6898129,6.5655232 q -0.9043347,0 -1.3900916,-0.4392482 -0.48575691,-0.4444159 -0.48575691,-1.1317103 0,-0.4030749 0.18086694,-0.733803 Q 1.1808659,3.9248659 1.4754206,3.7233285 1.775143,3.5217911 2.1472121,3.4184385 2.4210963,3.3460917 2.9740324,3.2789126 4.100575,3.1445543 4.6328406,2.9585197 q 0.00517,-0.1912022 0.00517,-0.2428784 0,-0.568439 -0.263549,-0.8009822 Q 4.017893,1.5994339 3.3150958,1.5994339 q -0.6562886,0 -0.9715139,0.2325432 Q 2.0335243,2.0593527 1.8836631,2.6432945 L 0.97416082,2.5192715 Q 1.0981839,1.9353296 1.3824033,1.5787634 1.6666228,1.2170295 2.204056,1.0258273 2.7414892,0.82945751 3.449454,0.82945751 q 0.7027973,0 1.1420456,0.16536406 Q 5.0307478,1.1601856 5.2374529,1.4133993 5.444158,1.6614454 5.52684,2.0438498 q 0.046509,0.2377108 0.046509,0.857826 v 1.2402305 q 0,1.2970743 0.056844,1.6433053 0.062012,0.3410634 0.2377109,0.6562886 H 4.8963895 Q 4.751696,6.1521131 4
 .710355,5.7645411 Z M 4.6328406,3.6871551 Q 4.1264132,3.8938602 3.1135583,4.0385537 2.5399517,4.1212358 2.3022409,4.2245883 2.0645301,4.3279408 1.9353394,4.5294783 1.8061487,4.7258481 1.8061487,4.9687266 q 0,0.3720691 0.2790519,0.6201152 0.2842195,0.2480461 0.8268203,0.2480461 0.5374331,0 0.9560109,-0.2325433 Q 4.2866096,5.3666338 4.4829794,4.9583913 4.6328406,4.6431661 4.6328406,4.0282185 Z" />
</svg>

This is a perfectly valid document under any automated validated system I can imagine.

It also happens to be a single letter "a", rendered in the Arial font.  My browser shows it as almost identical to following document:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 6.2891302 7.5190253" height="7.5190253mm" width="6.2891302mm">
  <text x="0.43156" y="6.4415" style="font-size:10.5833px;font-family:Arial;fill:#000000;fill-opacity:1;stroke:none"><tspan>a</tspan></text>
</svg>

"Almost identical" matters here.  The differences are down to variations in the font rendering of the tool that produced the path and the browser.  This is common.  It's also why some authoring tools deliberately turn fonts into paths; variation is something graphic designers will want to avoid in most cases.  In this case, it's a feature.  Even if RFC 8899 looks different in Firefox and Chrome or on Windows and Mac, the differences are reflective of individual preferences.

The only way I can think of that would catch this class of problems is to review the source of SVG carefully.  It also means developing extensive guidelines on the use of diagrams.  Automation can catch mistakes we know about (like including colour or using features that are known to cause problems in different renderers), but it is impossible to catch everything.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 11 Oct 2021 21:55:40 -0700

> "Almost identical" matters here.  The differences are down to variations in the font rendering of the tool that produced the path and the browser.  This is common.  It's also why some authoring too…

I suppose we have already opened that particular Pandora box, but this 
comment about graphic designers makes me sad. The goal of the RFC is to 
clearly lay out a protocol specification, or maybe some requirements or 
other informational documents. The focus is to convey the document in a 
variety of media. The design goal is to prevent the meaning from being 
altered, not to faithfully represent all details of a graphic. So, yes, 
I agree with Martin about  "differences [that] are reflective of 
individual preferences."

I guess this will boil down to requiring something like a text 
alternative, that would be rendered whenever the presented SVG is too 
complex or otherwise inadequate for the targeted platform, plus maybe a 
clarification that the SVG cannot be normative, only the text can be.

-- Christian Huitema

---

From: "John Levine" <[email-masked]>
Date: 12 Oct 2021 15:24:16 -0400

>It also happens to be a single letter "a", rendered in the Arial font.  My browser shows it as almost identical to following document:

I think we can have editorial guidelines saying not to do silly things.  The point of a diagram
in an RFC is to inform the reader, not to make a statement about the author's aesthetic politics.

As I would have thought we agreed long time ago, when we switched to XML, that meant that
nobody has perfect control over the appearance of a document, and that is a feature.  The HTML
resizes to the user's screen, can zoom in and out for those of us with fading eyesight, and
can be read aloud by screen readers, at least assuming authors don't play tricks.

For mechanical checks, I would think that if the ASCII art had strings of text and there were
no corresponding <tspan> in the SVG, that's a strong hint that the picture needs to be redrawn with a better
tool.

R's,
John