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

Michael StJohns <msj@nthpermutation.com> 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.

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.

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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

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

Attachment: signature.asc