[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Behdad Esfahbod
Subject: Re: [ft-devel] Major bug with varfonts named instances when avar table present
Date: Tue, 1 Aug 2017 15:00:33 +0100

On Tue, Aug 1, 2017 at 1:24 PM, Werner LEMBERG <address@hidden> wrote:

> What you mean is, it's not valid in this context.

Exactly.  We are *only* talking about the valid `psid' values for
*named instances*!  It's fully OK to restrict the possible indices
*for this specific case* to 6, 256-32767, and 0xFFFF.

What do you mean "fully OK to restrict"?  Do you think the spec saying so stops font developers from using other numbers?  I'm trying to minimize pain for the consumers of the API.
> I'll ask Peter to remove it.  Just because the spec says so, doesn't
> mean fonts wouldn't do otherwise.

I don't understand why you want that.

Because such requirements are unnecessary, and only make spec longer and enforcement harder without gaining anything.

> My point is: nameid 0 is a valid nameid.  By using 0 to mean "not
> set" in this context, you are requiring all clients of this
> particular API (fvar) to check for nameid==0 and call that invalid.
> In reality, most will forget and just pass it to the name table and
> get the copyright notice back.  Just use 0xFFFF which is used for
> this purpose all across the spec.

I've just pushed a change to do that, as announced in a previous



reply via email to

[Prev in Thread] Current Thread [Next in Thread]