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: Sun, 26 Feb 2012 15:28:27 -0800
To: Cameron McCormack <cam@mozilla.com>
CC: Edwin Flores <eflores@mozilla.com>, Sairus Patel <sppatel@adobe.com>, "public-svgopentype@w3.org" <public-svgopentype@w3.org>
Message-ID: <D23D6B9E57D654429A9AB6918CACEAA980713E8234@NAMBX02.corp.adobe.com>
It's not just about color, Cam - it's about the entire model, rendering system, etc.

Forget about color - how would you expect your SVG renderer (that is part of an OpenType engine) to know how to put "ink on paper"?  I wouldn't - I would expect it only to know how to put "bits in a bit buffer".  However, that's USELESS to a printer.


-----Original Message-----
From: Cameron McCormack [mailto:cam@mozilla.com] 
Sent: Sunday, February 26, 2012 5:44 PM
To: Leonard Rosenthol
Cc: Edwin Flores; Sairus Patel; public-svgopentype@w3.org
Subject: Re: Two flavors of glyphs: color-specifying and color-inheriting

Cameron McCormack:
>> I think in our SVG-in-OpenType spec we can just define how these 
>> input paints get translated into SVG paint values

Leonard Rosenthol:
> No, you cannot do that!
> You are thinking about a "Web" or "Screen" only world - but OpenType
> is used EVERYWHERE!   Think about all the places that you see fonts
> used that aren't working in an (s)RGB world or where the final output 
> isn't a "bit buffer".  The most obvious, and common, being a physical 
> printer.  Printers are CMYK (or CMYK+other) inks being placed onto a 
> physical media.  How do you expect your SVG renderer to know what to 
> do in that case??  There is no "bit buffer" for it to render into.
> Also consider other hardware devices, perhaps even in monochrome 
> devices such as teletypes, billboards, scrolling text signs, etc..

That's why I talked about SVG Color, with which you can represent CMYK colours.
Received on Sunday, 26 February 2012 23:29:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:50 UTC