Re: [rfc-i] SVG/A specification.

[Leonard Rosenthol <[e-mail]>]

>> Style
> It presents a problem for validation and for the aggregation of XML2RFC + SVG* to on XML document. Basically, it means that the validator has to understand the style sheet language.
>Since the output language is XML2RFC which prohibits style, it seems simplest to simply flatten all this out.
>
OK, I’ll buy that for Stylesheet.  But not for style.  Style is simple – it’s just ‘key/value’ pairs.

> But the original reason for this was not actually the archival part but the accessibility part.
>It is much easier to restrict attributes to a limited palette of colors if there is a single means of expressing them.
>
That may be true for colors *but* style also is where you define things like line-width, line-joins. dash patterns, font weight, etc.

And what about the ID restriction?

> So the only way to make this happen would be to expand the SVG Font definitions inside the diagrams. Which isn't going to happen. Pity.
>
No, the correct way to do this is simply to “embed” the font, as I recommended.  See https://www.htmlgoodies.com/beyond/webmaster/serving-up-base64-encoded-custom-fonts.html

Leonard

From: Phillip Hallam-Baker <[e-mail]>
Date: Friday, January 24, 2020 at 12:46 PM
To: Leonard Rosenthol <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [rfc-i] SVG/A specification.

On Fri, Jan 24, 2020 at 10:21 AM Leonard Rosenthol <[e-mail]<mailto:[e-mail]>> wrote:
Since you (assumedly) named this to align with PDF/A (the archival subset of PDF), then since I am the project leader for PDF/A, I think it’s only appropriate for me to weigh in.

Given your definition of archival (which seems fine), I believe that you have not fully thought through all of the requirements necessary to achieve that.


  *   Encapsulation.

     *   Great starting point and your definition aligns well with PDF/A.  However, your implementation does not.  For example, you allow for fonts by reference – which is not permitted in PDF/A (and was, IIRC the first requirement that was ever put into that standard).  All font information *must* be embedded, since is impossible to determine what fonts will be available at any time in the future.   This is especially true for any font/content that uses “special areas” of Unicode such as math.

  *   Accessibility

     *   You aren’t actually doing anything here to address this.  Where are you requirements around associating alt text (at a minimum)?  If you are going to call this out, if nothing else, you need to at least point to WCAG requirements here.  Either that, or I recommend you drop this requirement.

You are also missing a key requirement:


  *   (No) Scripting

     *   Removing any scripts that could change the content in the future was the #2 requirement applied to PDF/A and I would say also needs to be applied to RFC’s.  Not only to prevent content changing but also to prevent an RFC from accessing a remote site when being viewed (which also falls into the “encapsulation” category).
Oh good point! Given that I am probably the person who has detested Javascript longer than any other human being (I was at W3C when Netscape faxed us the spec and was the first to try it there), nobody seems to have thought it needed mentioning.

Also, you have some requirements that don’t have anything to do with archival requirements and AFAICT serve no useful purpose.

·         The stylesheet element MUST NOT be present.

·         The id and style attributes MUST NOT be present
Why??   As long as everything is internal and does not include scripting – what is wrong with CSS/stylesheets?   Same with the style & id elements?   They are all perfectly valid and archival.

It presents a problem for validation and for the aggregation of XML2RFC + SVG* to on XML document. Basically, it means that the validator has to understand the style sheet language.

Since the output language is XML2RFC which prohibits style, it seems simplest to simply flatten all this out.

But the original reason for this was not actually the archival part but the accessibility part. It is much easier to restrict attributes to a limited palette of colors if there is a single means of expressing them.


  *   If a diagram uses symbols from a different font, the specific glyphs used can be imported as SVG fonts.

SVG Fonts (https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/SVG_fonts<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FWeb%2FSVG%2FTutorial%2FSVG_fonts&data=02%7C01%7Clrosenth%40adobe.com%7Cc21f84ace0e2436c33e408d7a0f56862%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637154848188313724&sdata=utMREGB081JD1BlpRrPXrQjYKy8wiSDxrSUeHc22qCY%3D&reserved=0>) are not supported by any modern browsers and should not be used.  However it is possible to embed fonts into an HTML/SVG files, conceptually as one does with PDF.

So the only way to make this happen would be to expand the SVG Font definitions inside the diagrams. Which isn't going to happen. Pity.