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

I've been thinking about SVG-in-OT fonts and the more I think about it the more it bothers me.

Why does it bother me?   Because it is taking the font industry back in time 25 years(!!!) to the days of "Printer Fonts" and "Screen Fonts".   Granted, these "screen fonts" will be scalable and look better than the bitmap fonts of yore - but all of the same problems (and more) will be coming back with a vengeance!   

I don't know how many of you lived through those days but I did, and do NOT wish to do it again.  And back then, there were a LOT LESS people with computers and printers...

I don't necessarily have a solution, but I really think that this needs some serious thought because "Those who cannot remember the past are condemned to repeat it".

Leonard

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

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 Monday, 27 February 2012 14:27:00 UTC