[mpeg-OTspec] RE: Final (was Tentative) schedule for the AHG meeting

[Levantovsky, Vladimir]

On Thursday, January 09, 2014 4:56 AM William_J_G Overington wrote:
> 
> Once it is realized that a CPAL code could sometimes refer to something
> other than a colour, either as "totally transparent and (something
> else)" or as a stand alone code, various advanced facilities become
> theoretically possible.
> 

Even if something is possible it doesn’t mean it's appropriate or desired thing to do. CPAL (i.e. Color PALette table) is there to define color, and IMO should *not* be used to define "something other than color". If one needs to define *something other than color* it needs to happen *somewhere else* and not in the color palette table.

> As various ideas may develop over time, it seems a good idea to plan
> for a future situation where backward compatibility with what is being
> standardized in 2014 may well be needed.
> 

We do this by way of using version numbers for each defined table. Any new features that may need to be defined in the future will require both accommodating new facilities to implement them and preserving backward compatibility - table version numbers allow this to happen with no disruption to existing implementations.

> 
> For example, preset colours such as various colours of metallic ink.
> 

How is it different from defining sRGB pixel values for display purposes? 
The colors you see on screen are presented as collection of pixels, each having a predefined sRGB value. I agree that applications may require support for more than solid color definitions, and displaying something that looks like metallic ink may need support for both color and transparency gradients but I don’t see how this can be accomplished by simply reserving a palette entry in CPAL table.

> ----
> 
> For example, "totally transparent and sounds a beep".
> 
> So, for example, that a particular colour glyph could have two layers,
> a symbol in red in one layer and a glyph in "totally transparent and
> sounds a beep" in a layer on top of it.
> 

I strongly disagree with the premise of mixing different functionality in a font. Font defines a way how text content is visualized - one of the fundamental design principles here is that font defines visual shape representations for each unit of text display and remains completely agnostic to the semantics of that unit. In other terms, font defines what character 'a' looks like but not what it means. Combining anything that gives a particular unit of text display special meaning is the violation of this basic design principle.

> I am thinking that such a possibility might become useful in
> telemedicine applications where the red glyph could provide a visible
> and audible warning if a monitored value went out of range.
> 

As far as beep is concerned - it is the job of an application to analyze the input data and determine the appropriate response for it. If a certain monitored value is out of range, the application may produce either visual stimuli or a sound or both (or a smoke signal, if one wishes to do so), but it should not rely on something else (and certainly not on a font in use) to ensure the required application behavior.

Regards,
Vladimir