W3C home > Mailing lists > Public > public-svgopentype@w3.org > February 2012

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

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Wed, 22 Feb 2012 17:30:24 -0800
To: Sairus Patel <sppatel@adobe.com>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA980713E7FA8@NAMBX02.corp.adobe.com>
Good to know that I still agree that we need both types....and I still believe that it is important to know outside of the glyph definition which type it is because it has a HUGE impact on how the "parent rendering system" is going to call on it and use the result.

If we continue to use Postscript/PDF Type 3 fonts as the model, then I see no problem mixing and matching the two glyph types inside of a single font.

I do, however, think that we should consider a similar (but perhaps extended) set of restrictions on the "shape only" type.  For example, the "shape only' Type 3 glyph is not just forbidden from color operators but also from image operations - just a shape.  In the same vein, I think that it also needs to forbid animation.

Opacity is more interesting, since it's not just simple opacity - it's potentially a rich transparency model that can't be duplicated in SVG.  So I have to take a similar position, that for shape-only, no opacity operations allowed - but they would be fine in the other type.

I also continue to hold the position that glyphs can NOT draw outside their bounding boxes.  If you want a bounding emoticon that spans a larger space - then you use the emoticon glyph and animate it around your page.  But the glyph itself can't be drawing on top of my other content.

Leonard

From: Sairus Patel
Sent: Wednesday, February 22, 2012 7:49 PM
To: Leonard Rosenthol; public-svgopentype@w3.org
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<mailto: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<mailto: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 Thursday, 23 February 2012 01:30:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 23 February 2012 01:30:53 GMT