- 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>
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. Leonard -----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