Re: [Bimi] [EXTERNAL]Re: [rfc-i] SVG P/S Feedback

[Kirk Hall <[e-mail]>]

Here is input from Serge Mister of Entrust Datacard.



The mention of fonts as a risk is interesting (I'd flagged missing-glyph as a risk for similar reasons; but it sounds like some renderers ignore the glyphs even if they are present?).  Personally I've had trouble generating SVGs (for work illustrations) that use fonts because the same fonts aren't available on the different platforms (e.g. Linux and Windows), so I agree that in practice logo designers would want to convert their text to curves (both to avoid rendering issues and to save space).



The SVG native effort does sound like it has similar goals.  Just based on reading the introduction it does sound like it would be nice to combine the efforts.  I wonder if there would be any funding (I'm thinking from BIMI) for adding support for the output format to InkScape.  That would go a ways to helping with adoption.  I don't know what it would cost.





-----Original Message-----
From: bimi <[e-mail]> On Behalf Of Brian E Carpenter
Sent: Friday, August 28, 2020 3:26 PM
To: Brotman, Alex <[e-mail]>; [e-mail]
Cc: BIMI (IETF) ([e-mail]) <[e-mail]>
Subject: [EXTERNAL]Re: [Bimi] [rfc-i] SVG P/S Feedback





Alex,



I have to say that the RFC7996 profile of SVG Tiny is, in my experience, a problem rather than a solution. It was designed with the best possible intentions and some of the rules (like no colour, no greyscale, and no external references) are appropriate for the RFC context, but trying to generate conformant SVG with popular and widespread drawing tools is almost impossible**.



** Even with dia, which is a pretty minimal tool, some post-processing of the SVG may be needed. Producing my own recent effort (https://www.ietf.org/id/draft-carpenter-eligibility-expand-04.html#section-appendix.a) was quite a saga.



Regards

   Brian Carpenter



On 29-Aug-20 00:57, Brotman, Alex wrote:

> Hello,

>

> [Apologies for the cross-posting]

>

> As part of a separate project, we wanted to create a smaller SVG profile[1].  It is based on SVG Tiny 1.2, with several components removed.  The goal is to try to keep the document self-contained, remove animations, and generally more portable and secure (hence P/S).  Personally, I've been curious if we should be trying to create a new baseProfile as we've specified, given that it may behoove a developer to only target this subset of Tiny features, reducing footprint and attack surface.  We also welcome feedback about the text and font elements that we've permitted in the draft, and their security implications.

>

> We thank you for any advice or feedback you can provide.

>

> [1] https://datatracker.ietf.org/doc/draft-svg-tiny-ps-abrotman/

>

> --

> Alex Brotman

> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast

>

> _______________________________________________

> rfc-interest mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

>



--

bimi mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/bimi