Proposed clarifications to the "SVG Integration" doc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed clarifications to the "SVG Integration" doc

Sairus Patel
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

Reply | Threaded
Open this post in threaded view
|

Re: Proposed clarifications to the "SVG Integration" doc

Amelia Bellamy-Royds
Hi Sairus,

I've made up an issue in our GitHub tracker for these concerns: https://github.com/w3c/svgwg/issues/145

If you're able to create a pull request on the repo for any or all of these concerns, that would help move things along.  If not, it will get done, but the SVG Working Group's focus the next month is getting SVG 2 to Candidate Recommendation status.

At a glance, your concerns all seem valid, but I haven't done a careful review myself.  I'm copying Bogdan Brinza who was the last one to do updates on that spec, even if he didn't add himself to the editors list.

Best,
Amelia Bellamy-Royds

On 20 May 2016 at 17:54, Sairus Patel <[hidden email]> wrote:
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


Reply | Threaded
Open this post in threaded view
|

Re: Proposed clarifications to the "SVG Integration" doc

Nikos Andronikos

On 24 May 2016, at 9:04 AM, Amelia Bellamy-Royds <[hidden email]> wrote:

Hi Sairus,

I've made up an issue in our GitHub tracker for these concerns: https://github.com/w3c/svgwg/issues/145

If you're able to create a pull request on the repo for any or all of these concerns, that would help move things along.  If not, it will get done, but the SVG Working Group's focus the next month is getting SVG 2 to Candidate Recommendation status.

At a glance, your concerns all seem valid, but I haven't done a careful review myself.  I'm copying Bogdan Brinza who was the last one to do updates on that spec, even if he didn't add himself to the editors list.

FWIW, he is listed on the Editor’s Draft.

Once these changes are in it’s probably worth publishing a new Working Draft for OpenType to refer to.

Nikos.
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.