On Tue, 11 Feb 2025 at 11:21, Alexis Rossi <alexisrossir...@gmail.com> wrote:
> > > On Mon, Feb 10, 2025 at 11:15 AM Brian E Carpenter < > brian.e.carpen...@gmail.com> wrote: > >> Martin, >> >> That mainly sounds right, except for one point: >> >> > Specifically, the suggestion that the RPC favor accepting SVGs from >> common tools. >> >> What users need, I think, is a statement (very likely somewhere like >> authors.ietf.org, but that's a detail) saying that a certain set of >> drawing tools has been found by experience to be suitable, and that a >> certain other set has been less suitable. That seems like a suggestion, >> rather than a policy. >> >> However, I disagree with you that the text in the -00 draft is a >> suggestion. Rather, I think it should be two distinct policy items: >> >> * The RPC's implementation should strive to allow SVGs produced by widely >> used drawing tools. >> >> * Where possible, implementation decisions should focus on specifying >> what is disallowed, rather than attempting to specify exactly what is >> allowed. >> >> > The current version at > https://github.com/alexisannerossi/id-svgsinrfcs/blob/main/svgsinrfcs.md > has Martin's changes and also incorporates a notification requirement (from > Carsten's email). > I think the document should say something about not using (or embedding) custom fonts. SVG should be restricted to the generic font families that HTML & PDF formats use. i.e. 'serif', 'sans-serif' and 'monospace'. --Kesara > Do you feel like the new over all format - separating "policy > requirements" from "implementation guidance" - hurts the document? (eg > splitting those things out separately means the RPC might not feel bound to > support widely used drawing tools, or similar?) > > > >> Regards >> Brian >> >> On 10-Feb-25 17:46, Martin Thomson wrote: >> > On Fri, Feb 7, 2025, at 08:33, Alexis Rossi wrote: >> >> Hi all, >> >> >> >> This ID (co-authored with Nevil and Jean) is meant to obsolete 7996 >> >> with text that more clearly specifies the policies for inclusion of >> >> SVGs (and leaves out implementation details). Most of the policies in >> >> here are drawn from 7996. >> > >> > I think that this general direction is good. I've sent in a pull >> request that is part editorial, part substantive. >> > >> > https://github.com/alexisannerossi/id-svgsinrfcs/pull/3 >> > >> > The substantive part is to move some of the bullet points to a >> "suggestions" section, rather than make it policy. Specifically, the >> suggestion that the RPC favor accepting SVGs from common tools. >> > >> > I've also sharpened the policy section to highlight the two key points: >> > >> > 1. This empowers (or burdens) the RPC with the power to determine what >> SVGs are and are not acceptable. (In the text I propose, I've identified >> the potential for there to be both technical and editorial constraints. If >> it isn't obvious what that might mean, I'm happy to expand on these; I >> don't that taxonomy is exhaustive.) >> > 2. That responsibility also comes with a responsibility to document the >> decisions that are made. >> > >> > Again, splitting that between policy requirements and guidance makes >> that easier. >> > >> > --- >> > >> > I've suggested some minor guidance: >> > * That documentation serves a primary purpose (what will be accepted) >> and secondary purpose (help people produce good diagrams). >> > * That the RPC periodically review and revise their practices. >> > >> > --- >> > >> > On the substance of the list, which I didn't touch in the above: >> > >> > * "SVGs in RFCs must render well on a wide variety of common devices" >> is untestable as worded. Should this instead state the aspiration that "as >> many people as possible should be able view the image"? That's still >> squishy, so maybe it can move to implementation guidance rather than policy. >> > >> > * The requirement to propagate SVGs to publication formats that support >> them is seems awkward. I think that the goal is: where there are multiple >> choices of how to present a figure -- and there is no reason to show >> multiple -- the best (that can be supported in the target format) shall be >> selected. You might mention that this is expected to be SVG in many cases. >> > >> > * With the changes I propose, the statement "SVG vocabulary and >> implementation may change over time and is not required to remain >> backwards-compatible." is a bit redundant. >> > >> > --- >> > >> > Other than that, I think that the general direction here is sound and >> I'm supportive of retiring RFC 7996. >> > >> > >> > >> > -- > rswg mailing list -- rswg@rfc-editor.org > To unsubscribe send an email to rswg-le...@rfc-editor.org > -- Kesara Rathnayake Senior Software Development Engineer - IETF Administration LLC kes...@staff.ietf.org
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
