RE: EOTL font file specification version 1

On Friday, August 07, 2009 7:42 AM Mikko Rantalainen wrote:

> Checking for version numbers, feature flags or magic numbers
> cannot guarantee that the font data can be loaded (e.g. it could be
> corrupted by mistake or because of malice).
> 

Agree, but it can help to easily (and with minimal overhead) identify those cases when font data cannot be loaded.

> 
> I'd would assume that the OS/font subsystem that is trying to load the
> OpenType font already checks if the input file is indeed a valid
> OpenType font. Any additional checks before that are wasted CPU time
> for a valid font file. And hopefully the OS/font subsystem is sane
> enough to immediately return if an error is found. So that is not an
> optimization even for invalid fonts. (There can be additional
> optimizations but none of those need to be codified by the
> specification.)
> 

An attempt to load an invalid font would result in much more overhead and wasted CPU time. Checking flags to see if this can be completely avoided seems to be perfectly reasonable and useful; and it would require much less of CPU time to check whether particular bits in a bitfield are set vs. making a function call and see if it returns an error condition. I agree that the spec doesn't need to spell out for implementers what can be optimized and how to do it, but since the flags are part of the header data, the spec should at least identify the location and the meaning of those flags, IMO. 


Vladimir

Received on Friday, 7 August 2009 13:43:45 UTC