RE: Two flavors of glyphs: color-specifying and color-inheriting

Edwin,

> is by defining two new paint server values for SVG that will only be valid within SVG glyphs

Why would this be specific only to SVG glyphs? Shouldn’t any SVG be parameterizable in this way?

Here are a couple of key points in how I see this:

1. In as many ways as a standalone SVG image can be parameterized (animated or not, stroke width, fill color/pattern, etc.) -- in those exact ways, an SVG-in-OT glyph should be able to be parameterized; nothing more, nothing less.
 
2. Implementations will differ on which of the above parameters they support (whether for standalone SVG or for SVG-in-OT charstrings). For some applications, animation or specifying stroke width may never be enabled, for example. And that's fine; such applications shouldn't be in non-conformance to the SVG-in-OT spec.

Sairus


-----Original Message-----
From: Edwin Flores [mailto:eflores@mozilla.com] 
Sent: Wednesday, February 22, 2012 6:29 PM
To: Sairus Patel
Cc: Leonard Rosenthol; public-svgopentype@w3.org
Subject: Re: Two flavors of glyphs: color-specifying and color-inheriting

The way we have approached this in our implementation is by defining two new paint server values for SVG that will only be valid within SVG glyphs: `objectFill' and `objectStroke', which inherit the context's fill and stroke values, respectively.

That is, if the parent context were to have the colour set to "red" and an element inside the SVG document were to have fill="objectFill", that element would be coloured red. This also generalises to gradients and patterns.

This way we can mix specified and inherited paints. A basic use case for this would be a smiley face where the colour of the face changes with the context colour, but the eyes stay black and white.

In our implementation, fill="objectFill" and stroke="objectStroke" are the default values at the document root, so if the author doesn't specify a paint it inherits in from context.

We plan on also having objectFillOpacity and objectStrokeOpacity, and objectValue for other values we might want to inherit (e.g. stroke-width, fill-rule).

Thoughts?


Edwin

----- Original Message -----
From: "Sairus Patel" <sppatel@adobe.com>
To: "Leonard Rosenthol" <lrosenth@adobe.com>, public-svgopentype@w3.org
Sent: Thursday, February 23, 2012 1:48:32 PM
Subject: Two flavors of glyphs: color-specifying and color-inheriting




(Spun off from another thread item, which I've appended below.) 



Our SVG OT spec should allow for: 



a. some glyphs to specify their own color(s), and 

b. some glyphs simply to inherit the color of the surrounding style, without specifying their own color(s). 



(a) is of course a requirement for the project itself: specific colors or combinations of colors that are inherent to the graphical intent of the glyph. Examples would be a green-skinned, red-tongued alligator face emoticon (U+1F61D), or representations of an Indian street-painter’s multicolored lettering. Such glyphs would be unaffected by the surrounding style’s color. 



(b) is similar to what's done for TT and CFF today, and would be used for glyph shapes that need to avail of some aspect of SVG other than color. For example, a titling font that morphed in weight back and forth between regular and bold could use this flavor of glyph. 



1. In SVG, how would this happen? Is it simply a matter of some glyph definitions in the document specifying color, and others not? Would there be a problem mixing such glyphs in the same document? 



2. Would there need to be an indication of the flavor of glyph outside of the SVG document data, so that the OT engine can read it and know in advance what flavor it was? Or would it be enough for the SVG renderer to return that in the rendered result? 



[ As Leonard points out below, Type 3 fonts in PostScript and PDF have a similar kind of distinction (setcharwidth and setcachedevice operators for (a) and (b) in PostScript; d0 and d1 in PDF). The PostScript operator names were in effect cache control directives, and exposed the fact that the PostScript font cache could only cache masks, which in turn was a sensible decision since alpha mask glyphs, our flavor (b), was most likely in need of optimization. Type 3 fonts were also used for arbitrary containers of PostScript procedures that could be conveniently invoked with character code strings, and such fonts used the setcharwidth flavor since caching of the output marks wasn’t relevant. ] 



All the above is re. color. 



As for opacity, I believe the surrounding style’s opacity should be applied to the result of the SVG renderer, regardless of whether the glyph is of flavor (a) or (b). Thoughts? 



Sairus 









-----Original Message----- 
From: Leonard Rosenthol 
Sent: Wednesday, November 23, 2011 12:45 PM 
To: Sairus Patel; public-svgopentype@w3.org 
Subject: Re: [OpenType] Update on color/animation in OT via SVG; new W3C Community Group 



Good stuff - thanks!! 



A bit more on the page compositing item. 





On 11/23/11 3:04 PM, "Sairus Patel" < sppatel@adobe.com > wrote: 

>- Compositing with the rest of the page: 

> 

> My interface sketch-up did indicate to rasterize a glyph at a 

> particular (x,y) location but was silent on whether it should be 

> composited. My feeling is that compositing should happen if we can get 

> away with a simple enough model. What is done for SVG images placed on 

> an HTML page today in browsers? Does compositing happen? 

> 

> In the CFF and TT model, the rasterizer returns an alpha map that is 

> then composited into the rest of the page. 



Perhaps unlike others, I am looking at this feature for NON-WEB content. 

If this SVG is inside of a standard OTF font, then it could/will be installed into a user's OS and they can choose this font in Word or OpenOffice or InDesign for authoring. And then there is a high probability that they'll create a PDF from that content. So, at some point in the future, all of these non-web applications have be able to render these new glyph descriptions. SVG rendering is well defined BUT traditionally only when considered BY ITSELF. 



Now we have a situation where the SVG has to be rendered INTO THE MIDDLE OF some other context, with all of its state information (ie. Position, color, alpha/opacity, etc.) applied to the result of the SVG render (since it can't all be passed in, as SVG doesn't necessary implement all the same features, or the same feature in the same exact manner). 



It may also be worth looking at Postscript/PDF's Type 3 font model (which was the original impetus for SVG fonts after all) which provides for TWO DIFFERENT types of glyphs - one which is inherits a set of attributes from the parent (such as color) and one which does not. As I don't completely understand all the use cases for this work, I can't say if it's necessary 

- though it's starting to sound it more and moreŠ 



Leonard

Received on Wednesday, 6 June 2012 21:21:14 UTC