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

[Brian E Carpenter <[e-mail]>]

On 17-Dec-20 11:02, Michael Richardson wrote:
> 
> Michael StJohns <[e-mail]> 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.

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.)

> 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.

Yes, hence the ban on colour and greyscale.

   Brian

> 
> 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.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest