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

Leonard Rosenthol lrosenth at adobe.com
Mon Jan 20 11:41:07 PST 2020

Phillip – “issues” with SVG are entirely contextual.    When used in the context of a full “Web Platform User Agent” (aka a browser showing a web page), then there aren’t any issues because (as you note) that is the environment it was designed for.  However, use of SVG in other environments (eg. SVG inside of OpenType fonts - https://docs.microsoft.com/en-us/typography/opentype/spec/svg) requires a subsetting.   As I mentioned in a previous message, you can see what the OpenType and SVG committees (and others) are doing so subset SVG for their needs at https://github.com/adobe/svg-native-viewer.


From: rfc-interest <rfc-interest-bounces at rfc-editor.org> on behalf of Phillip Hallam-Baker <phill at hallambaker.com>
Date: Monday, January 20, 2020 at 2:33 PM
To: Brian Carpenter <brian.e.carpenter at gmail.com>
Cc: "rfc-interest at rfc-editor.org" <rfc-interest at rfc-editor.org>
Subject: Re: [rfc-i] No, constraining to a custom SVG profile is not trivial

It is not just the greyscale that is the issue. There are numerous issues in the diagrams that result from the chosen profile.

Compare the diagrams in:

With the originals in:

Getting the diagrams to present properly is at least two weeks work for me on top of the weeks already spent. And I am probably not going to be the last person making this set of complaints. I am just the first person who developed specs that depend on having good diagrams in them.

On Wed, Jan 15, 2020 at 10:21 PM Brian E Carpenter <brian.e.carpenter at gmail.com<mailto:brian.e.carpenter at gmail.com>> wrote:
> Attached is a simple XSLT script that I created that simply rips out invalid elements.

The problem with colour/greyscale is that this isn't enough. If you have very dark blue text on a very pale pink background, what happens? svgcheck makes this black on black; my heuristic makes it black on white. What would your script do?

But I do agree with Phill, this is a non-trivial issue. Currently I think doing new drawings with a simple tool like DIA is the only practical way.

It is my opinion that a standards organization should stick to existing standards rather than inventing its own. Deviation from W3C standards should only happen with an incredibly good reason. I do not see one.

Telling people to use one particular tool looks like bullying behavior to me. Forcing people top jump through hoops to produce the old plaintext format was bullying which was one of the reasons I was so opposed to it.

SVG is ubiquitously supported in current generation browsers. There are tens, probably hundreds of thousands of person years worth of effort invested in creating SVG content using today's tools. There is a published spec that is widely distributed and at least as certain to survive whatever apocalypses might occur as RFCs.

RFCs are merely tools for making the Internet change. We are not writing holy scripture here. All RFCs that have the slightest importance are going to have errors. The question is not how to eliminate the errors but to minimize them.

Moving to HTML greatly reduces the number of errors in interpretation.

Allowing unrestricted SVG has plenty of issues too.

Nobody ever gives a specific issue. That is not how a standards organization should behave. If there is a need to vary any standard, either our own or someone else's there should be a clearly articulated reason given.

Please state specific issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200120/ee8ca149/attachment-0001.html>

More information about the rfc-interest mailing list