FW: [mpeg-OTspec] Color fonts technology in OFF / Proposal from the Adobe Type Team

[Caleb Belohlavek]

Vlad-

Thanks very much for making this an official effort. At Adobe, members of the Adobe Type Team feel it is the right time to extend the OFF/OpenType specification, which can only result in overall added value for type users, content consumers and the type industry as a whole. Visual richness is something that we see burgeoning across the web, numerous devices and the traditional desktop. It only seems appropriate that we broaden the capabilities of type - something that is so pervasive and essential for expressive communication around the world.

We are pleased by recent efforts by many of our partners (Apple, Google, Microsoft) and their color font initiatives. While many of these efforts surround the addition of color for the express purpose of offering richer emoji fonts, we feel that we should be looking well beyond that toward the future. As Dr. Ken Lunde, our CJKV type expert said, "When you do open heart surgery, you'd best fix anything else that needs fixing while you are in there. You don't want to have to crack that chest, again." A somewhat graphic analogy, but at Adobe we feel that if there is going to be an effort to modify the spec, then let's add functionality from which everyone can benefit - functionality that customers and developers can use for the next ten years or so.

While the addition of color is a nice start, we feel there is an opportunity to also add:

-Scalability (bitmap solutions can solve some problems but are functionally restrictive)
      Designs which can be used in multiple sizes across multiple devices
      Design once, use everywhere
-Color gradients (Move beyond solid color)
-Support for Animation (even if not implemented initially)
      Fonts which grab the attention of the viewer
      Animation support to show stroke sequence and direction (for teaching writing / Asian font education)

Adobe has been interested in this functionality for some time. Please check out a Flash-based example of how an SVG-based solution could be used:

http://www.adobe.com/devnet-apps/type/EmojiGradient.html

This example, designed by Ryoko Nishizuka in our Tokyo office, offers vector-based content which is both animated and supports gradient areas. While yet another example of an emoticon solution, this could be expanded to support any kind of display font which could benefit from color, animation or scalability.  Examples are creative titling, drop-caps, other display usage in digital publishing (HTML pages and e-magazines); online advertisements, and e-learning materials. It is our belief that this functionality could be addressed by using SVG. Our recommendation would require the addition of an SVG table to the OFF which could, not only provide solutions for color, but also provide for the added functionality noted above. Already a part of the HTML specification, as well as supported in many software programs and devices, the SVG model when combined with the next OFF standard could provide the basis which will help us get closer to bringing the same visual richness we currently enjoy in print to the screen.  Sairus Patel, of our CoreType team, can speak more deeply to the technical requirements and has been working with the Mozilla team to promote SVG support in OpenType fonts.

Below is a shortened summary of the requirements categories you suggested in your previous email:

-Expressiveness
      The list above falls into this category
      The model can support developer defined color specification (not locked into colors specified by the designer)
-Compatibility with existing glyph mechanisms
      Monochrome instance of the font is supported as usual
      SVG table and added functionality ignored if not supported
      SVG renderer called when table is present
-Performance
      Font file size is always a consideration, but should be a decision made by the content creator based on their targeted consumers
      Constrained devices will ignore added functionality
      While this added functionality may increase file size (negative impact to download performance), this may not be a concern in the future as technology improves (Moore's Law)
      Asian fonts similarly continue to suffer from the same problems due to file size.  We need tech solutions (compression, glyph streaming, etc.) to solve for this problem anyway.
-Rendering environment constraints
      For many constrained environments, this added functionality will not be desired, <however>
      Device manufacturers will continue to differentiate based on functionality.  We can provide them with design options if the spec is expanded to support more functionality.
-Scalability and co-existence
      Adding additional functionality doesn't preclude support for bitmap-based solutions for constrained environments
      Fonts created with SVG support will not be limited to a fixed size, but can be scaled up or down to suit the environment or the needs of the designer

Finally, I would like to make a case for the value proposition: For content consumers, more expressive fonts will provide for visually richer customer experiences. For content creators, straight out of the box (or should I say "straight out of the font") enriched fonts will provide designers with solutions which require little tweaking - are ready to go, and can help draw attention to web content. For font foundries, added functionality provides new opportunities to build new types of fonts, or add additional functionality to their existing libraries and sell upgrades. Think of the large markets around clip art and stock photography. Typographers may want to do much of this themselves, but for every knowledgeable type user, there are plenty of potential content creators who will need a solution but don't have the time to create it themselves.

Caleb

______________________
Caleb Belohlavek
Principal Product Manager * Type
Adobe
caleb at adobe.com<mailto:caleb at adobe.com>
408.536.3706

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20130724/cbd5274f/attachment.html>