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

From: Kirk Hall <[email-masked]>
Date: Tue, 1 Sep 2020 23:14:27 +0000

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 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Friday, August 28, 2020 3:26 PM
To: Brotman, Alex <[email-masked]>; [email-masked]
Cc: BIMI (IETF) ([email-masked]) <[email-masked]>
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

> [email-masked]<mailto:[email-masked]>

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

--

bimi mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Sep 2020 11:46:38 -0400

On Mon, Aug 31, 2020 at 10:34 AM Brotman, Alex <[email-masked]>
wrote:

> Brian,
>
> We've sort of seen the same issue, though we expect that tools will
> catchup over time.   That being said, I know that Inkscape does not today
> support SVG Tiny 1.2 as an export format.  Illustrator does a reasonable
> job with Tiny, though seems to have a few bugs during export.  I haven't
> yet tried Dia or Scribus (I believe it also supports export to SVG).   Even
> with support in tools lacking today, we'd like to work toward this goal of
> creating this format.  We've had good success thus far getting images to
> conform without skewing the intended representation.
>

Tooling will not catch up. There is 0% chance of that.

SVG Tiny is deprecated. It was created a decade ago for the same community
that creates WAP. The notion was that there was a demand for a smaller SVG.
There was not. As a result only one major vendor ever supported SVG Tiny
and only in one tool And that support will almost certainly be removed in
future as all mention of SVG Tiny is removed from the SVG specs.

I have tooling that converts SVG Tiny to the IETF subset but the process
adds absolutely nothing. It is stupid makework. I get angry every time I
have to deal with this crap. The results are not good and cannot be made
better without hundreds of hours of effort. The RFDC Interest group has
absolutely no interest in even understanding why the situation cannot be
made to work for document preparation.

Basically there is a group of people who will write no code or even bother
to understand the problem that nevertheless insist that the decision they
took with no understanding of the issues five years ago must stand for all
time.

To understand the problem, look at
https://www.ietf.org/id/draft-hallambaker-mesh-architecture-14.html

Scroll down to figure 3 and you will notice the arrows aren't there. Nor
are some of the symbols. The problem is that every program that generates
SVG output uses macros to generate the line endings. That is why they exist
in the first place. But SVG tiny doesn't have that capability so the line
endings are lost. The issue with the symbols is that even though the RFCs
are unicode and the symbols used are very common, there is no specification
of which symbols the tools accept.

If you understand how SVG is used you will quickly understand the reason
why there is absolutely no chance of it being more widely supported. Nobody
uses this format so there is zero demand for it. The implementation effort
is non trivial. It requires someone to write a full SVG stack and render to
SVG Tiny. People used to do that stuff back in the 2000s before the iPhone
came out and people suddenly realized that mobile devices were not going to
be running a 'Web Lite'.