Re: [ft-devel] Major bug with varfonts named instances when avar table present

[Werner LEMBERG]

> Ah, Werner!  How I wish you were here!  No one wants to use the
> copyright notice as the name of a named instance.

:-)

>   Allowing this is completely insane!
> 
> Basically you are saying anything that constitutes garbage should be
> disallowed by specs.  I fully disagree.

No, I don't say that.  However, name IDs < 256 have fixed meaning, so
it makes sense to restrict them.  It would be fully OK with me if the
specification used a negated style, for example:

  All name ID values can be used except value 0.

This probably makes more sense.

>> Any font validation tool must catch that.
> 
> Hasn't stopped people from shipping broken fonts...

Indeed.

>> What API?
> 
> Ok maybe I'm wrong here.  I assumed the psname-id is exposed to
> FreeType client. 

It is (in the `FT_MM_Var' structure), but FreeType only interprets it
if it is value 6 or in the range [256;32767].

> Thinking about it now, probably it's not and you just expose the
> postscript name; maybe even not that yet.

It does.  In case `psid' is missing, FreeType constructs a PostScript
name using `strid' (i.e., the instance record's `subfamilyNameID'
field).

> At any rate, my whole argument was that zero is a valid name ID and
> should not be used to mean "not present".  I know you already
> addressed that.

Yep.

>> I still believe we are miscommunicating.  Name ID values < 256 have
>> a fixed meaning, right?  Of those values only index 6 (the
>> PostScript name) makes sense for named instances.
> 
> No.  If my font has nameID 1 set to "Skia" and an instance wants to
> be called "Skia", it should be perfectly legal to refer to nameID 1.
> The fact that those have fixed meaning is irrelevant.  It's their
> values that is being referenced here.  The fixed-number aspect only
> comes in when they are needed for that fixed purpose.

Hmm.  Your point of view is different from the OpenType specification.

> To pull real example: [...]

OK, point taken.  However, I'm like a burnt child that dreads the fire
– there are so many loopholes and exceptions in the OpenType
specification (especially in the interpreter part) that a clean-room
implemention is essentially impossible.  We always have to emulate the
MS behaviour for the shadowy parts.  This is extremely annoying and
exhausting.

> To summarize, "who would want" is not how we should write specs.
> Any requirement in the spec should have a logical derivation that
> does NOT rely on what you or I can think of as legitimate use-cases
> today.

I agree.  Then let me rephrase the issue: *FreeType* only supports
name ID values 6 and [256;32767] for `psid' :-)


    Werner