From nobody Tue Sep 1 16:14:38 2020 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23533A041B for ; Tue, 1 Sep 2020 16:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHF0uiwzW7Y5 for ; Tue, 1 Sep 2020 16:14:35 -0700 (PDT) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1BD3A041C for ; Tue, 1 Sep 2020 16:14:34 -0700 (PDT) IronPort-SDR: D22joRahbkhMCVpfQ8FcEqd+rb9lF5JsRiV+pbvAoTUGA0/E/IkTyY0e0OemvwP3B8aUNDRyY6 aNm2i/ukwEDg== X-IronPort-AV: E=Sophos; i="5.76,380,1592888400"; d="scan'208,217"; a="19393922" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 01 Sep 2020 18:14:33 -0500 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Sep 2020 18:14:28 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Sep 2020 18:14:28 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W+qJUugO4og0tZ5fhuWWWNRDiYi5rraOkacqZ/s+pvd4CZUmLuQwNWtKtBT2kSUioYtBNZ/T+mM6FnUaVI3vIm9JH7b/3zZ+2+WG/qwX3SOjVwAVUwfkSGOTZ4LM36yHV59JDEM0gSeDywGutXU4ZzUlF1Rst1ve3YuQFj+hTm2s1+zVYPsf6wT2VcxgxMuKDixiVlEf4j1fD7Xi/RlNKeB1BbMsul5QFOLUMyICwUvF6rJZs8XPL0+CnrNEEb8THyH4oChkSHYa7xO6KrhDixP3/+7zQqBWuGV3CWA8IvJpyB7S/X/sVStgVvHevtc6bUdbx8hC7KrpALCviAZNjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O1okKQlphPw49qZzmHUwn5BJUwZo+bvt8M5n33WRQV0=; b=XVBLHnETIMss7awJQW2FnzKU3HQbyPmeKhZxuCRDT0HGcK1OElsUFgPv+zZ+XDocsFP40Jcg3lJvEIaxtnHw0ZRzcvcAi9TuoidNt9Ayb2ZU9S2NkgO2ZxzKp+JWaxi9AV/f8O+oM6k31IRA9L9ZL8OU+SQ3KSk7saRAKuihR7Ivx3PEhGKdXQzIj6xIPJvV/t3T2e8iV5BBpxJN7lBiYMd+g7ZgB49cZx/ARxBwU+kTjuLXWfdtzsfvr3Jp0Jt3x3zeLcxy8bK4QaUFzeUeGWXpt8NvJKYZi5/AIMOB7LnvIOe5uw+j6gjdW/TuWo7AzOKKVRetDn356Bw7SR9Y1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O1okKQlphPw49qZzmHUwn5BJUwZo+bvt8M5n33WRQV0=; b=FER58xYzDRC34X2Bpz6KbJuTQGAbpnNElRedsLFImPan6bRUqSCdXmZt4tOQX8cDuHQRq0yfUtjQysXjyWIutTOvJg/WCQW0+0XW5c4nGtrqF46mX77WUS1PaLRkkeb7YyFrngLEIjTYOnqYdPzLUl4xq6OuvXhHUFyIogs7TPI= Received: from DM6PR11MB4427.namprd11.prod.outlook.com (2603:10b6:5:1db::20) by DM6PR11MB4580.namprd11.prod.outlook.com (2603:10b6:5:2af::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Tue, 1 Sep 2020 23:14:28 +0000 Received: from DM6PR11MB4427.namprd11.prod.outlook.com ([fe80::79e0:c4e1:f2ab:3a6f]) by DM6PR11MB4427.namprd11.prod.outlook.com ([fe80::79e0:c4e1:f2ab:3a6f%7]) with mapi id 15.20.3326.025; Tue, 1 Sep 2020 23:14:28 +0000 From: Kirk Hall To: Brian E Carpenter , "Brotman, Alex" , "rfc-interest@rfc-editor.org" CC: "BIMI (IETF) (bimi@ietf.org)" Thread-Topic: [EXTERNAL]Re: [Bimi] [rfc-i] SVG P/S Feedback Thread-Index: AdZ9Okv+69BoULslTL+Cfd/XcqlzFQAT+0OAAMrUSlA= Date: Tue, 1 Sep 2020 23:14:27 +0000 Message-ID: References: <70eadfe5-16f6-47d9-4cb8-f4f9bffdd355@gmail.com> In-Reply-To: <70eadfe5-16f6-47d9-4cb8-f4f9bffdd355@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=entrustdatacard.com; x-originating-ip: [2601:1c0:7000:b4b0:6ca6:b5a2:9c92:4401] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b058a489-2f5a-496e-6f35-08d84eccc650 x-ms-traffictypediagnostic: DM6PR11MB4580: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JrNupqEF6VCTXkB8o+VTUS/i3Cqx9EbRjV5GlXC79tVDvkcDqxNKjUa1sRSqKqVZNVpwHLD9zmnWV4E8ZxruHw9XorgXsx1aZs0Bhkp4nGY5VAQejv4dp64DmxQXH+o1fV8kNv31C7aeKdhWZBdhjXvUvc5YeRBovPLXa8HZ0PRTaq2sQte+qkPQzODeWqgo3GHdWhv66xZG+Pf7dDewtRlp2GL4koAUo+UD16V92NSXZ3sO3JcZ/h3yK1OBBWwsoFtccgzwA+WXDsQzkQ5RBsG2CVT8HmKz1sAC7ywMZ7GFawKMs2c/vKinueTYsHDyaIBxyBa4i5M2L6VwDszBcIEV6r1KgclOKzGAm0XylBnGzHHaOjHTmeHsPd3DSEgs4Nc51jhH9m2HaFvw7EVmHg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4427.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(366004)(346002)(39860400002)(376002)(83380400001)(64756008)(8676002)(66556008)(66946007)(66476007)(316002)(966005)(86362001)(76116006)(66446008)(166002)(4326008)(33656002)(478600001)(55016002)(9686003)(2906002)(71200400001)(52536014)(110136005)(186003)(5660300002)(6506007)(7696005)(8936002)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: w7XHaKkgMt6b3Vq5Ft2/NXoBEEITQrK5he1DQA13pbPuvkvz9hMt3qA6iHoNH0IuHhncQde2Hmbcx7QxIU92VDDyBkNdwvSp62nhJOWpyfLS9qFTBfFyNbBvSfGuaEWH8UkRbRBpBhMA5A6hSpzFkK/ebIUyX6IUjjvazErRWOy+zQ6YfW988v9krXGATuUmqaDRTOBJ26U+iqYh98/a9W+JDMhScnAk6kqgfmYukHHg8traaCsYRyoW5s9OzEbBAMZgZSrGxVDLsjSNsg3+fNI4Ae+vErCexN2LZznjvPQS3/TQEOEZP3Xn4C5+u37VFjeowHf+o3mNJj6gO3m+s8TLsnbu/Vkjc7/ylNt70BQ/V1OcgFMNXz93Y22RYdbxY1JAlWx0QM+KKiXJzZJTCT2fNONX5p11aKJRpxZDOnWBAuBsGyvva0reF2ytn9jEpDz9fqoKamhMHBrbTvXi/pNtPUTG/ZbqLnje9UuoWmv7hMIqAmHoYdnHF8AWJ/+plPh2D8rfs1u3QCONJclCx8Sjxku+VTRZYwEtBO+GPQb+wqRS9VLMpBSMWZWLFNFvoMvSmM/88WiBvcEWUN+50dyrCMNFZBdm0qJK+nRmMrsE3Kz5zR47RJ1qsQD7kKZciOYd/5avkBjDVzmux+3+gRtnF8rXRu3Ex36+QRXxqOL7Ch44x2vWWubVVXp1UgF/Ctfbm80Ya80BAmI7yn1beg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB44270A168B195C8E45ABD297F22E0DM6PR11MB4427namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4427.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b058a489-2f5a-496e-6f35-08d84eccc650 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 23:14:27.8781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MH72KrKwGy63w7Wr8s7tIXNV8vIEAsUDFv7x94An8outFfdHCvEfH4Wq3e1EsALB8j9607BNyojW49iiBijfhYJQyGZai9mf0pi8cYfQhjk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4580 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [Bimi] [EXTERNAL]Re: [rfc-i] SVG P/S Feedback X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 23:14:37 -0000 --_000_DM6PR11MB44270A168B195C8E45ABD297F22E0DM6PR11MB4427namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 g= lyphs even if they are present?). Personally I've had trouble generating S= VGs (for work illustrations) that use fonts because the same fonts aren't a= vailable on the different platforms (e.g. Linux and Windows), so I agree th= at in practice logo designers would want to convert their text to curves (b= oth 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 On Behalf Of Brian E Carpenter Sent: Friday, August 28, 2020 3:26 PM To: Brotman, Alex ; rfc-interest@rfc-editor.org Cc: BIMI (IETF) (bimi@ietf.org) 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 inte= ntions and some of the rules (like no colour, no greyscale, and no external= references) are appropriate for the RFC context, but trying to generate co= nformant SVG with popular and widespread drawing tools is almost impossible= **. ** Even with dia, which is a pretty minimal tool, some post-processing of t= he 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 goa= l is to try to keep the document self-contained, remove animations, and gen= erally 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, giv= en that it may behoove a developer to only target this subset of Tiny featu= res, reducing footprint and attack surface. We also welcome feedback about= the text and font elements that we've permitted in the draft, and their se= curity 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 > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest > -- bimi mailing list bimi@ietf.org https://www.ietf.org/mailman/listinfo/bimi --_000_DM6PR11MB44270A168B195C8E45ABD297F22E0DM6PR11MB4427namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is input from Serge Mister of Entrust Dataca= rd.

 

The mention of fonts a= s a risk is interesting (I’d flagged missing-glyph as a risk for simi= lar reasons; but it sounds like some renderers ignore the glyphs even if th= ey are present?).  Personally I’ve had trouble generating SVGs (for work illustrations) that use fonts because the same f= onts aren’t available on the different platforms (e.g. Linux and Wind= ows), so I agree that in practice logo designers would want to convert thei= r 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 intro= duction 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.  Tha= t would go a ways to helping with adoption.  I don’t know what i= t would cost.

 

 

-----Original Message-----
From: bimi <bimi-bounces@ietf.org> On Behalf Of Brian E Carpenter
Sent: Friday, August 28, 2020 3:26 PM
To: Brotman, Alex <Alex_Brotman@comcast.com>; rfc-interest@rfc-editor= .org
Cc: BIMI (IETF) (bimi@ietf.org) <bimi@ietf.org>
Subject: [EXTERNAL]Re: [Bimi] [rfc-i] SVG P/S Feedback

 

 

Alex,

 

I have to say that the RFC7996 profile of SVG Tin= y is, in my experience, a problem rather than a solution. It was designed w= ith 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 eff= ort (https://www.ietf.org/id/draft-carpenter-eligibility-expand-04.html#s= ection-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 se= veral components removed.  The goal is to try to keep the document sel= f-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 tha= t it may behoove a developer to only target this subset of Tiny features, r= educing footprint and attack surface.  We also welcome feedback about the text and font elements that we've permi= tted in the draft, and their security implications.

>

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

>

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

>

> --

> Alex Brotman

> Sr. Engineer, Anti-Abuse & Messaging Pol= icy Comcast

>

> ____________________________________________= ___

> rfc-interest mailing list

> rfc-interest@rfc-e= ditor.org

> https://www.rfc-edito= r.org/mailman/listinfo/rfc-interest

>

 

--

bimi mailing list

bimi@ietf.org

https://www.iet= f.org/mailman/listinfo/bimi

 

--_000_DM6PR11MB44270A168B195C8E45ABD297F22E0DM6PR11MB4427namp_-- From nobody Mon Sep 21 08:47:06 2020 Return-Path: X-Original-To: bimi@ietfa.amsl.com Delivered-To: bimi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61563A0964 for ; Mon, 21 Sep 2020 08:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bJRY4mtUHQj for ; Mon, 21 Sep 2020 08:47:03 -0700 (PDT) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9839E3A08F8 for ; Mon, 21 Sep 2020 08:46:49 -0700 (PDT) Received: by mail-oi1-f180.google.com with SMTP id z26so17423149oih.12 for ; Mon, 21 Sep 2020 08:46:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NDBnHktJmnDWMRjX/pSz0zgZkzIrBrS+EoY2oIwixlU=; b=rfx8e7Civ8RGBov+sW3XuFqeLfCH/8Q7DIQ4q5gyqfw9sU7OaMUfIAEha4jX07JC0L e2BbKgrcvwOWoMMyuz5WwNabHu+r/hvO2xkJzlq8yHzi/YFnGxXCD4YeW3Ei5CAWRbam 7DN+ixB6DtvRZu2hLZCyMam/eAZjxRagknZ/P21WAaMdO+AG37XQcbXjN2o8Wx5dGdmr +n9y1ChWVvmcNi2fEQ3nE6Tvo2QcQJ9Y4Ym+wzJs/B84dAuNLnA82WHqLfl4lAwK0Cur hS4+1h0vDzOSUNpQByRkSxGdDeDtZMTnBz9YTFj0kSBtnvqmrob6HBbvFl9P/McuqjGj 1wMQ== X-Gm-Message-State: AOAM5312C27PXGyfNjhbhrOp+GyDbtB+sXej2hXTf4+yaz/PSAUo4krq uaUdAfGPZYsg+uGMAPvXARTmfz5AzRdUIoZ7jI0= X-Google-Smtp-Source: ABdhPJwOu/ldwaCxEfcZUPLTF7C451Mx9/lKPDnnlNuWcdEZX7n1a9YA3mLyBpu/MdUaDPUeUvAK6dSi+PPZ27+Nkkk= X-Received: by 2002:aca:bbd7:: with SMTP id l206mr74992oif.173.1600703208952; Mon, 21 Sep 2020 08:46:48 -0700 (PDT) MIME-Version: 1.0 References: <70eadfe5-16f6-47d9-4cb8-f4f9bffdd355@gmail.com> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 21 Sep 2020 11:46:38 -0400 Message-ID: To: "Brotman, Alex" Cc: Brian E Carpenter , "rfc-interest@rfc-editor.org" , "BIMI (IETF) (bimi@ietf.org)" Content-Type: multipart/alternative; boundary="0000000000002916b205afd4c22c" Archived-At: Subject: Re: [Bimi] [rfc-i] SVG P/S Feedback X-BeenThere: bimi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Brand Indicators for Message Identification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 15:47:05 -0000 --0000000000002916b205afd4c22c Content-Type: text/plain; charset="UTF-8" On Mon, Aug 31, 2020 at 10:34 AM Brotman, Alex 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'. --0000000000002916b205afd4c22c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 31, 2020 at 10:34 AM B= rotman, Alex <Alex_Brotman@c= omcast.com> wrote:
Brian,

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

Tooling will not catch up. There is 0% ch= ance of that.
<= br>
SVG Tiny=C2= =A0is deprecated. It was created a decade ago for the same community that c= reates 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 onl= y in one tool And that support will almost certainly be removed in future a= s all mention of SVG Tiny is removed from the SVG specs.

I have tooling that converts SVG Tiny to th= e IETF subset but the process adds absolutely nothing. It is stupid makewor= k. I get angry every time I have to deal with this crap. The results are no= t good and cannot be made better without hundreds of hours of effort. The R= FDC 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 neverthel= ess 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=C2=A0
https://www.ietf.org/id/draft= -hallambaker-mesh-architecture-14.html

Scroll down to figure 3 and you will notice the arrow= s 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 t= hat 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 wi= ll quickly understand the reason why there is absolutely no chance of it be= ing more widely supported. Nobody uses this format so there is zero demand = for it. The implementation effort is non trivial. It requires someone to wr= ite a full SVG stack and render to SVG Tiny. People used to do that stuff b= ack in the 2000s before the iPhone came out and people suddenly realized th= at mobile devices were not going to be running a 'Web Lite'.=C2=A0<= /div>

--0000000000002916b205afd4c22c--