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

[Brian E Carpenter <[e-mail]>]

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%7Cf8108cd02b334c72415d08d84bd8f976%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637342742565624784&amp;sdata=1m8XMdcHkgmgUCf%2B4%2F0wEOI37suRSejjVpsbqqsHXI4%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%7Cf8108cd02b334c72415d08d84bd8f976%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637342742565624784&amp;sdata=kN8z9faPWo3aCpTjdQNfyHn0W%2BelVT7%2BTdIW45CBtl8%3D&amp;reserved=0
>