W3C home > Mailing lists > Public > www-svg@w3.org > May 2016

Proposed clarifications to the "SVG Integration" doc

From: Sairus Patel <sppatel@adobe.com>
Date: Fri, 20 May 2016 23:54:23 +0000
To: "public-svgopentype@w3.org" <public-svgopentype@w3.org>, "www-svg@w3.org" <www-svg@w3.org>, Cameron McCormack <cam@mcc.id.au>, Dirk Schulze <dschulze@adobe.com>, Doug Schepers <schepers@w3.org>
Message-ID: <343D8ACF-6F01-4B6C-956E-C74AB3C13E29@adobe.com>
Hello Cameron, Dirk, Doug (the editors of the SVG Integration document), all:

I’d like to request the following changes to the SVG Integration document https://www.w3.org/TR/svg-integration/. This has come up in the context of the current revision to the OpenType-SVG specification. Please let me know if there is another process by which to move this along:


1.
In sec 2 > font document, change:

> must use the secure animated processing mode.

to:

> must use the secure animated or secure static processing mode.

Reason: As stated in OT-SVG, it is valid for a font-engine *not* to support animation. Thus either mode above should be allowed.


2.
In sec 2, font document, replace:

> This referencing mode is intended to used by the OpenType specification for processing documents from the "SVG" table.

by:

> The OpenType specification uses this referencing mode for processing documents from the ‘SVG ’ table. OpenType has a facility whereby color palette variables are provided in the above user agent style sheet as well; see https://www.microsoft.com/typography/otspec/svg.htm.



3.
Since it’s been addressed above, delete:

> Issue 4: Should the CSS Variables that map the palette colors into the document be defined here too? It probably makes sense to keep that in the OpenType specification.

Reason: It makes sense to have OT be the single place the color palette variables facility is defined in. It probably makes sense for OT to be the sole place the UA style sheet in ‘font document’ (sec 2) is defined in as well, though that isn’t part of this proposal.


4.
Sec 3.1 External References says:

> Issue 5: This is all too handwavy. And we perhaps shouldn't try to make an exhaustive list. This needs to be defined in terms of Fetch, probably. And the URL Standard for comparing the URLs.

I’d like to request that the document resolve this issue. I’ve heard concern from implementors about this “handwavy”ness.

Best,
Sairus

Received on Friday, 20 May 2016 23:55:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:04 UTC