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

Phillip Hallam-Baker phill at hallambaker.com
Mon Jan 20 11:32:20 PST 2020


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:
https://tools.ietf.org/id/draft-hallambaker-mesh-architecture-12.html

With the originals in:
https://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html

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> 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/d591baec/attachment.html>


More information about the rfc-interest mailing list