freetype-devel
[Top][All Lists]
Advanced

[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:24:47 +0100

On Tue, Aug 1, 2017 at 3:13 PM, Werner LEMBERG <address@hidden> wrote:
>> 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?

Yes.  Who wants to use, say, the copyright notice as the name of a
named instance?

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.

 
Any font validation tool must catch that.

Hasn't stopped people from shipping broken fonts...

 
> I'm trying to minimize pain for the consumers of the API.

What API?

Ok maybe I'm wrong here.  I assumed the psname-id is exposed to FreeType client.  Thinking about it now, probably it's not and you just expose the postscript name; maybe even not that yet.

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.

 
>> > 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.

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.

To pull real example: currently OpenType spec says "DFLT script system MUST have non-NULL DefaultLangSys".  I suppose someone like you would argue that "who wants to use a DFLT script with no DefaultLangSys"?  Well, someone argued the same.  Now when my subsetter subsets font glyphs and no lookups are left, it removes the empty DefaultLangSys, but keeps the empty DFLT script system because removing that alters the font's behavior.  As a result, the font just became invalid, and ots and hence Firefox reject it...

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.

 


    Werner



--

reply via email to

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