[mpeg-OTspec] Re: AHG conference call reminder

[Ken Lunde]

John,

I think you meant to use "component fonts" in the last paragraph for  
the second instance of "composite font."

But yes, I agree, and this is another case of when the Composite Font  
author may wish to specify a version for one or more component fonts.

And as daan and I have been advocating, the format should not require  
this, but it should be possible to set this.

Font formats are littered with required fields, and because they're  
required, and because some font developers don't care about those  
fields or simply don't know how to properly set them, they may have  
bogus or garbage values. If we were to do the same in the Composite  
Font format, it would significantly amplify this issue. Ambiguity at  
one level is bad enough, such as in a single font, but when it is at  
multiple levels, which is what Composite Fonts are all about, it  
should be avoided.

Regards...

-- Ken

On 2009/05/18, at 22:59, John Hudson wrote:

>
>
> Ken wrote:
>
> > What I was describing is the extremely conservative nature of the
> > Japanese printing industry, and that changes made to fonts, even if
> > they are considered to be corrections, are often unwanted or
> > undesired, because they represent changes. For this reason, some
> > Composite Font creators may wish to encapsulate or record the  
> specific
> > version of the font that was used, to ensure that the resulting
> > Composite Font is the same when it is consumed. Of course, this  
> field
> > is not required, and we're taking steps to ensure that very few  
> things
> > are required, but the format needs to have facility to specify this
> > level of detail, in case it is needed by a Composite Font creator.
>
> A more general case:
>
> It is possible that multiple versions of a component font may be
> installed on the user's system, in different locations but under the
> same name. Since different versions may have different levels of both
> character and glyph support, being able to identify the desirable
> version is important for correct display of documents using the
> composite font.
>
> I can imagine a few fallback options for a client that can't find the
> correct version or encounters a composite font in which this  
> information
> is not provided, but having a field for the correct font version  
> within
> the composite font header will be useful. I often work with user
> communities who require quite frequent updates to fonts, sometimes
> involving only a handful of new characters to support some particular
> language or even an individual document. Accurate version  
> identification
> is very important in such situations.
>
> I can imagine a composite font tool grabbing version strings direct  
> from
> the composite fonts, so even if the version string is not correctly
> formatted according to e.g. the OT font spec it will still be a valid
> reference in the composite font to that particular font.
>
> Regards, John
>
> -- 
>
> Tiro Typeworks www.tiro.com
> Gulf Islands, BC tiro at tiro.com
>
> I'm like that Umberto Eco guy, but without
> the writing. -- anonymous caller
>
>