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

[Levantovsky, Vladimir]

Whether something could or could not be done is not an argument here. Just because something could be done doesn't mean it should, and in this particular case, I'd argue that it should not. 

Thank you,
Vladimir

On Jan 11, 2014, at 7:46 AM, "William_J_G Overington" <wjgo_10009 at btinternet.com> wrote:

> Thank you for replying.
> 
>> 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.
> 
> Actually, that supposed quote is different from what I wrote, in that the word "code" was used and the word "a" has been left out.
> 
> This is a significant difference, because I am suggesting that in some cases a CPAL code need not refer to a colour yet that such a CPAL code could be used together with some CPAL codes that do each refer to a colour so as to produce a colour effect such as a gradient fill of two colours.
> 
> Certainly, I am also suggesting that in some cases a CPAL code need not refer to a colour yet could be used to produce a non-colour effect such as a beep.
> 
> Yet the two types of use of a CPAL code where the CPAL code does not refer directly to a colour are qualitatively different each from the other and I ask that they be considered separately please.
> 
> There is also the use of a CPAL code where the CPAL code does not refer directly to a colour, so as to produce animation.
> 
>> 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.
> 
> Well, I note the comment yet upon consideration I still think that reserving some CPAL codes for possible future special use could be a useful practical thing to do.
> 
>>> For example, preset colours such as various colours of metallic ink.
> 
>> How is it different from defining sRGB pixel values for display purposes?
>  
> I am thinking of being able to use a font in a desktop publishing application program, such as Serif PagePlus, so as to send from font designer to a printing house that prints hardcopy from a pdf document, the request to use a particular metallic ink as a spot colour.
> 
> The metallic ink being a physical substance.
> 
> I use Serif PagePlus version X6 at present, which allows including Pantone metallic items in a pdf as spot colours.
> 
>>> 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.
> 
> Well, I note those statements, yet 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.
> 
> For example, an emoji-like character, mapped to the plane 0 private use area at present, could be defined as follows.
> 
> Two red pales side by side with a gap between them on a white background with a sine wave sound of 440 Hertz lasting for 1 second followed by silence for 2 seconds, looping so as to produce a sound lasting for 1 second in every three second cycle continuously.
> 
> I suggest that it is useful to consider that if a major producer of mobile telephones added that character to the repertoire of emoji, and the character was later encoded into Unicode, how would a font encode that character?
> 
> Many such sound character might become encoded, maybe musical note symbols that each play a musical note, one such character for each note used in music.
> 
>>> 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.
> 
> Well, it depends upon the application scenario. If character codes within a private use area definition scenario were used to send data and a summary that could include an out-of-limit warning code from a measurement system over a telephone link to a central monitoring facility, then maybe such a facility in a font would be useful. I am not saying that such a facility in a font would definitely be useful, I am just saying that  maybe such a facility in a font would be useful: I therefore suggest that the idea deserves detailed consideration please.
> 
> William Overington
> 
> 11 January 2014
>