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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 30 August 2020 23:37 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 B69653A097B for <bimi@ietfa.amsl.com>; Sun, 30 Aug 2020 16:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.046
X-Spam-Level:
X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UuJ4fFOc_Q4w for <bimi@ietfa.amsl.com>; Sun, 30 Aug 2020 16:37:04 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 CCF0C3A0975 for <bimi@ietf.org>; Sun, 30 Aug 2020 16:37:04 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id ds1so2189659pjb.1 for <bimi@ietf.org>; Sun, 30 Aug 2020 16:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3Njx+dtm7NBMJ+QeR/HtPcqbObPtVL4ElNjOnbTJgrk=; b=oJP8KoicW6YHfkFGhGPOUFL3yi9i87r26yRCUp3GA5McdE7TLgldfFJF3ZV1+AuhED fuidXpTUqULn0OToiOBlvFySxP+ixPjgpDusr3YppY2hkw6MNGX0ThBVSIDqObbEhSix JdtWKGzBswMZPR6LOv0TzumpnivA1r55pSFXtgvQ5j5Z5y2J8yS/jDL4Sp/cGHH/BJq2 EKlmNe/FP/pHGg2zba+IFvC7JOfWrSZAYWMx3fEhWjftivNwqE3AUvab7Kjo6cZRmqEM CgNwJgTOlP870//faqBJoJgGysOWobEfDezvt4FGc6NIs1BPJrixgJjCIUK1AZcnx/JA GqMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3Njx+dtm7NBMJ+QeR/HtPcqbObPtVL4ElNjOnbTJgrk=; b=AdrX3y57pCRnRilKT1wyklusGiqF1FXDFdLl95B1HVZXoZhDcS3LqM6IpOkhowtCUc 0ZDAQdMXuIIDCFdo6cW6hLbFftqNeenfkSC0uxZwDvpZzxTzuzOOR7K5onS0nx/a32KJ fV41K9f3bt2N+QQDUKSV1hNnwSXOnQje33uDthEWdqg5SV/5KXiPyKDHWs5JrEWsL2Sy l8npTBtQea8FCTPFIcBv30MXzjHyh3g4C0vJk3GP9JLRh5qDOecieHXGb1v7rxOPBYZy ZZRCOlpCR5MZZSxUuvu4diK4pFN8kPoKOHbcap/dvOzGPmtzEapPD+hch7oBZM5qDw4A 6sjA==
X-Gm-Message-State: AOAM5319LZvim41T7bdWniAMaR6/O4zG6RhI7CJqIeX2BrJNseDnwMTz 5rRTQwRLQjj1swQT0I9h4ynvANd+5ik5Ww==
X-Google-Smtp-Source: ABdhPJyqa+50H9pDY+YZJBQDO2/Nq82aPTc1Pa2VDuV3KzhdhRey3cJqEAktmxLvurGRxmON7iYOlg==
X-Received: by 2002:a17:90a:bc48:: with SMTP id t8mr8545327pjv.224.1598830623804; Sun, 30 Aug 2020 16:37:03 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id v1sm5049205pjh.16.2020.08.30.16.37.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Aug 2020 16:37:02 -0700 (PDT)
To: Leonard Rosenthol <lrosenth@adobe.com>, Larry Masinter <LMM@acm.org>, "'Brotman, Alex'" <Alex_Brotman@comcast.com>, "rfc-interest@rfc-editor.org" <rfc-interest@rfc-editor.org>
Cc: "'BIMI (IETF)'" <bimi@ietf.org>
References: <MN2PR11MB4351CC443B406196C3953D1BF7520@MN2PR11MB4351.namprd11.prod.outlook.com> <70eadfe5-16f6-47d9-4cb8-f4f9bffdd355@gmail.com> <013c01d67d8e$5b952f60$12bf8e20$@acm.org> <f2df89d0-73c5-49b5-c18c-ec0ac16dfa1c@gmail.com> <290BCC09-02FB-4289-9D1A-2FD00B476E78@adobe.com> <53a7ca18-792f-ef67-24f9-e84e5e154989@gmail.com> <64DF8A7C-A219-45D9-9FE6-25D4CC8143EF@adobe.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <fccae6e7-dc47-426b-56bb-1da2da7235b4@gmail.com>
Date: Mon, 31 Aug 2020 11:36:57 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <64DF8A7C-A219-45D9-9FE6-25D4CC8143EF@adobe.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/z1TwFhYb2FdDJ9uCogE0clXVZ28>
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 <bimi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bimi>, <mailto:bimi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bimi/>
List-Post: <mailto:bimi@ietf.org>
List-Help: <mailto:bimi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bimi>, <mailto:bimi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Aug 2020 23:37:07 -0000

On 31-Aug-20 10:09, Leonard Rosenthol wrote:
> Brian - not sure what you are looking at, but in SVG 1.1 (https://www.w3.org/TR/SVG11/single-page.html#types-DataTypeNumber), I see the following definition for a `<number>`
> 
> 	<number>
> 	Real numbers are specified in one of two ways. When used in a style sheet, a <number> is defined as follows:
> 
> 	number ::= integer
>            		| [+-]? [0-9]* "." [0-9]+
> 	This syntax is the same as the definition in CSS ([CSS2], section 4.3.1).
> 
> 	When used in an SVG attribute, a <number> is defined differently, to allow numbers with large magnitudes to be specified more concisely:
> 
> 	number ::= integer ([Ee] integer)?
>            		| [+-]? [0-9]* "." [0-9]+ ([Ee] integer)?
> 	Within the SVG DOM, a <number> is represented as a float, SVGNumber or a SVGAnimatedNumber.
> 
> As noted, this is consistent with how "numbers" are used in the rest of the open web platform (eg. CSS, HTML, etc.)

Yes, and that's all fine. But when you start converting formats, and the round trip converts 
32.459999 into 32.424, there's clearly a problem of how real numbers work in a particular hardware and floating point library, and/or a difference in how real numbers are handled in the two formats. So specifying how real numbers are represented in various SGML dialects is only part of the problem.

I'm no expert on this, but https://en.wikipedia.org/wiki/IEEE_754 tells me that it's very complex and there are many cans of worms.

Regards
    Brian


> 
> Concerning use in PDF or PDF/A, I don't think that Larry was suggesting that it was being used *instead of* xml2rfcv3...but it is one of the normative formats produced from that grammar.   As such, I believe Larry was pointing out the importance of being able to roundtrip from the SVG in the xml2rfcv3->PDF/A->SVG for anyone that might need it.  As mentioned, there are methods to embed the original SVG directly into the PDF at authoring time and then that SVG could be extracted downstream. The tool used by the IETF supports that option, but I don't believe it is enabled.  Something to consider for the future.
> 
> 
>> Who is the arbiter of "correct fidelity"?
>>
> I would argue that data which is semantically identical is correct.  The fact that you can serialize the same data in different ways isn't bad - as they are semantically identical.  However I don’t see a need to debate that at this time...
> 
> 
> Leonard 
> 
> On 8/30/20, 5:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
> 
>     On 31-Aug-20 04:12, Leonard Rosenthol wrote:
>     > Brian - but what you describe below is a tooling problem not a technology or format issue.
> 
>     IMHO the underlying problem is that SVG allows multiple ways of representing the same image, and a subsidiary problem is that it allows positions to be represented as real numbers. The SVG spec says:
>     "Unless stated otherwise, numeric values in SVG attributes and in properties that are defined to have an effect on SVG elements must support at least all finite single-precision values supported by the host architecture."
>     In other words, the precision of positions is host-dependent. I don't know enough about PDF to know how that affects the conversion algorithm, but I suspect it means that...
> 
>     > There are ways in which all of the SVG semantics - or even the entire SVG itself(!) 
> 
>     ... only embedding the SVG itself would be guaranteed to round-trip in all cases. Since that is exactly what we do in xml2rfcV3, I don't see what we'd gain by doing it in PDF/A instead.
> 
>     > - could be included in the PDF/A file and round-tripped with correct fidelity (or even 100% identical bits).
> 
>     Who is the arbiter of "correct fidelity"? The judge and jury in a patent infringement or copyright case? The only safe standard is "identical bits" or at least "identical string of UTF-8 characters". We've relied on "identical string of ASCII characters" for many years.
> 
>     > Let's agree on what the goal is, come up with a standard that specifies how to achieve that, AND THEN we can get tools to comply.
> 
>     Sure. We'd need to start with some canonicalization rules for SVG. We need to look again at RFC7996 in any case. But I don't think that relying on host representation of real numbers is ever going to be OK. (Is there a reason that SVG didn't use a host-independent formulation for its statement about precision?)
> 
>         Brian
> 
>     > 
>     > Leonard
>     > 
>     > On 8/29/20, 1:04 AM, "rfc-interest on behalf of Brian E Carpenter" <rfc-interest-bounces@rfc-editor.org on behalf of brian.e.carpenter@gmail.com> wrote:
>     > 
>     >     Larry,
>     > 
>     >     On 29-Aug-20 10:55, Larry Masinter wrote:
>     >     > One of the functional requirements for SVG illustrations is that when
>     >     > converted to PDF/A that the result is "as good as it gets" so the authors
>     >     > don't rely on embedded animations or videos to explain the protocol they are
>     >     > describing.
>     >     > 
>     >     > What if you did a round trip   SVG -> PDF/A -> SVG. I think it's possible to
>     >     > insure that doing so is idempotent (if it isn't now).
>     > 
>     >     Only if you had a round trip tool that magically preserves the SVG dialect
>     >     in use. I just round-tripped a test file using https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconvertio.co%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Ccb6c5f20901348ae829808d84d28f979%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637344185664248727&amp;sdata=eN6bT%2FbUwXBQx6iRRWElVJaiZ4Tvw3DT0sV7hvn3Rwc%3D&amp;reserved=0.
>     >     The PDF and the round-tripped SVG *look* the same as the original, but the
>     >     actual content of the SVG file is totally different, and fails svgcheck, so
>     >     is no longer conformant with RFC7996. The converter just happens to choose
>     >     a different way of representing the same image, since SVG is so versatile.
>     > 
>     >     The converter also messed up the scalability of the image, which is really
>     >     annoying if you want the image to be viewable on a tiny screen.
>     > 
>     >     Now I'll round-trip it a second time... once again, the input and output
>     >     SVG files are different, although only in a few places. So even the
>     >     conversion tools at convertio.co can't achieve idempotency with the SVG
>     >     that they themselves generate.
>     > 
>     >     (For the record, convertio.co doesn't claim to be PDF/A conformant,
>     >     but I think that's beside the point here.)
>     > 
>     >        Brian
>     > 
>     > 
>     >     _______________________________________________
>     >     rfc-interest mailing list
>     >     rfc-interest@rfc-editor.org
>     >     https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmailman%2Flistinfo%2Frfc-interest&amp;data=02%7C01%7Clrosenth%40adobe.com%7Ccb6c5f20901348ae829808d84d28f979%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637344185664258722&amp;sdata=mM1UUMwFMAvTOrS9ongBH1OoQHxHJ6OIv0cQQHNsdvQ%3D&amp;reserved=0
>     > 
> 
>