- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Mon, 4 Feb 2013 05:46:06 -0800
- To: Cameron McCormack <cam@mcc.id.au>
- CC: "public-svgopentype@w3.org" <public-svgopentype@w3.org>
On 2/4/13 4:38 AM, "Cameron McCormack" <cam@mcc.id.au> wrote: >>That all assumes that you control the SVG renderer, but in most cases, >> that's not the case. > >You need some amount of control over the SVG renderer. You definitely >need to prevent script from running, which otherwise could be a security >problem. And that's going to be a problem for getting this implemented in pretty much every other browser and in the OS contexts. >>Is it reasonable to have the design of SVG glyphs in OpenType be >>constrained by what WebKit on iOS can do? Just WebKit on iOS - maybe. But that was a single example of a larger problem. Unlike Mozilla, most/all of the other browsers use the OS-provided text drawing services. Same for many authoring tools and other types of UAs (ebooks, etc.) They don't have their own font engines. That means that they are going to have to wait for the respective OS vendors to support this feature before they can support it. For an OS vendor to support it, means that they are going to now have to bridge their HTML/SVG engine with their font engine. And start figuring out all the new APIs that are required (as I tried to demonstrate in my original email). I would really like to see representatives from Apple, Google and MSFT review and comment on their willingness (or lack thereof) to implement this. Because w/o their support - the whole concept of "SVG in OT" is dead in the water. >All SVG glyphs should be renderable either as static or animated glyphs. > You shouldn't need to have to annotate this. If your implementation >or situation does not support animation, then you still use the SVG glyph. Now you are putting a burden on the font author, that they have to create SVG that works in both cases. What if they donšt want that? What if they only want the SVG for animation and are OK with the classic glyph for static rendering? Since they have to provide classic glyphs anyway, why also force them to provide SVG versions of those glyphs? >>>I don't understand why this is possible if there is a predefined bbox >for the glyph and not if there is not. Being a "pre-defined" area for >the glyph doesn't mean that it has exclusive rendering rights to that >rectangle; there is probably some other pixel data in that spot that it >would be rendering on top of. Why does this change if the glyph just >paints to the extents determined by its actual graphics content? I feel >like I am missing something. Because the SVG engine may not have any idea how to paint to the actual graphics context. You are assuming that the SVG engine and the application drawing text are using the same graphics libraries, etc. That's not always the case. >>1 - Require the caller to provide SVG-compatible "paints" for the current >> graphic state to the font renderer. But if a caller can't tell in advance that a given glyph requires this feature, then it is going to have potentially a HUGE amount of overhead to create these values and then pass them - even if they don't get used. That's going to kill performance for something that may never be used. The caller needs to be able to specify that it wants to allow this or not. It also needs to be able to easily determine if it's going to be used (w/o having to parse the SVG). Leonard
Received on Monday, 4 February 2013 13:46:38 UTC