Re: issues with OpenType spec referencing the SVG Integration draft

On Mar 13, 2014, at 10:59 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> Here is the current draft of the OpenType spec that includes SVG glyphs:
> 
> https://xa.yimg.com/kq/groups/12860955/740362423/name/w14124_14496-22_WD6_3rd_ed-redline%2Ezip
> 
> Comments are due by March 24, and then there will be a meeting of the MPEG group that works on OpenType in early April.  We need to send comments to their list by March 24 if we want particular changes accepted in the April meeting.
> 
> From discussion on today's SVG call, it sounds like there are two issues we need to decide on:
> 
> 1. Whether we want to leave the definition of how particular SVG features work in font documents -- such as disabling <foreignObject> and <text> -- in the OpenType spec itself, or if we want to have it reference one of our documents, like SVG Integration, so that we can update it more quickly than we could make updates to OpenType.
> 
> 2. Whether the current reference to SVG Integration for the "secure animated mode" (which is where the requirement to disable script etc. currently comes from) is acceptable, given we haven't published a Working Draft.
> 
> 3. (Which we didn't mention on the call but is also worth discussing:) If we do define (1) in the SVG Integration document, whether that document should also define the user agent style sheet that maps the palette stuff into CSS Variables.
> 
> If we are going to leave the reference to SVG Integration in the OpenType spec, then we should make a concerted effort to publish a Working Draft of it so that we can point to www.w3.org/TR/svg-integration/ or whatever stable URL it will have.  I'd be happy with removing (temporarily or until the next version) anything that would stop us from publishing a draft with the bits we need.
> 
> I can put in the work (and probably should have already) to get SVG Integration published.
> 
> I personally would be happy with the approach of (1) defining in SVG Integration a term "running as a font document" or something like that, off which we can hang our requirements to disable <foreignObject> and <text> rendering, which can be updated for versions of SVG >1.1; and therefore (2) leaving the reference to SVG Integration.  I am happy for (3) to remain in the OpenType spec.
> 
> It sounded like Dirk you feel differently.  Can you summarise your view?
> 
> As I mentioned I can't call in next week, so if we can come to a decision on the list here that would be good.

I know that Doug initiated the SVG integration document as a way that other specifications can reference SVG and leave the details to SVG integration. This is most certainly a valid goal.

On the other hand, I think the main focus should be more on a security and fetching model for SVG initially. The need can be seen by all these security concerns we are faced with in CSS, Filter Effects, Masking and many other parts of SVG. The integration modes should build on top of these fetching and security models. We may be able to reach both goals, the different models as well as the basic foundation at the same time. But I don’t think that starting with the models without a foundation does help anyone. I started a document (same folder as the current integration spec) that tries to start with the foundation. I am happy to work together with other editors to extend the spec by different models including a font rendering model.

I do not think we should rush the document just because SVG Open type fonts need a solution right now. If SVG Open type does need something now, it should specify the model on its own. But it may still fail with it because of the missing foundation.

At this point I do not see SVG Integration close enough to a FPWD. We have the F2F upcoming to change that. It needs a lot of efforts though.

Greetings,
Dirk

> 
> Thanks,
> 
> Cameron

Received on Tuesday, 18 March 2014 22:00:34 UTC