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

On 21-Jan-20 08:32, Phillip Hallam-Baker wrote:
> It is not just the greyscale that is the issue. There are numerous issues in the diagrams that result from the chosen profile.

No colour or greyscale was a choice, not an issue. Because people wanted both printability and accessibility, the choice was made to get rid of colour-impaired sight problems and cheap printer problems.

The only other big problem I'm currently aware of is scalability. There are some interactions between browsers and elements like viewBox, width="724.0" and height="485.135549872".

I also discovered that any any <?xml ...> or <!DOCTYPE ...> declarations must be removed from the SVG file.

Hopefully the Temporary RFC Series Project Manager can coordinate some systematic approach to identifying SVG issues, both in tooling for the existing subset and possible updates to the subset. As Leonard Rosenthol hinted, unrestricted SVG is not really an option.

   Brian

> 
> 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@gmail.com <mailto:brian.e.carpenter@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.

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest