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

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Jan 24, 2020 at 10:21 AM Leonard Rosenthol <[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) 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.