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

[Leonard Rosenthol <[e-mail]>]

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.)

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" <[e-mail]> 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" <[e-mail] on behalf of [e-mail]> 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
    >     [e-mail]
    >     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
    >