[MPEG-OTSPEC] [EXTERNAL] Relaxation of CFF2 hint requirements (?) in variable fonts

[Hin-Tak Leung]

 For some of its current usage, the word "master" can be replaced with "primary". The other usage, and in plurals, "masters" (as in variable fonts) are really corner states / extremas . There is probably a better word to mean a "pure instance" of some sort?
"primary/primaries" probably can work? "primary source data"? "Source primary"?
    On Monday, 5 February 2024 at 21:04:50 GMT, Thomas Phinney <tphinney at cal.berkeley.edu> wrote:  
 
 IIRC, we had a (very lengthy!) discussion of this same issue internally at FontLab back when I was CEO.
We never came up with an alternate word that seemed workable for the font data concept. “Main” really does seem singular in a way that “master” is not necessarily.
If somebody proposes a good alternative word, I expect people would be happy to entertain a change request—I just couldn’t think of something.



On Mon, Feb 5, 2024 at 12:53 PM Hin-Tak Leung via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:

 That reminds me - the git/git[hub,lab,...] people have been moving away from "master" as the name of the default branch, to "main", because of the word's colonial connotations.
Maybe the opentype spec should avoid the word "master" for that reason too.
    On Monday, 5 February 2024 at 20:44:15 GMT, Peter Constable via mpeg-otspec <mpeg-otspec at lists.aau.at> wrote:  
 
 Hi, Skef

The term "master" should not be used in the way you have in this doc. The variations overview section uses the term, defining it as "a set of source font data... used in a font-development workflow". It could be used elsewhere in the spec with that meaning, but the wording should make clear that it refers to source data. 

In your doc, it's not clear whether you mean "instance" or a default value combined with a (not attenuated) delta. The latter concept necessarily has to refer to some specific value in the font, which could be an outline coordinate, a metric value, or any other single, variable value. But when it comes to data in the font file there is nothing that corresponds to a source master.


A question about this: I gather that this would require changes in CFF2 rasterizers?


Peter

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Skef Iterum via mpeg-otspec
Sent: Monday, February 5, 2024 3:23 AM
To: mpeg-otspec at lists.aau.at
Subject: [EXTERNAL] [MPEG-OTSPEC] Relaxation of CFF2 hint requirements (?) in variable fonts

A short proposal to relax the requirements on stem hints in a CFF2 variable font should be attached. These changes (or clarifications -- see below) are comparable to allowing overlap in CFF2; what could easily be normalized away in a static context winds up being needed in a variable context.

Note that these changes do not affect the storage format, and one could argue that one or even both is compatible with the current standard (given that nothing much is said on the subject). Still, they may raise issues about versioning. My sense is that if a font built according to the clarifications is rasterized on a system assuming total ordering of stems and/or no duplicate stems, the result will be as if some stems are missing rather than overt distortion of a glyph. And the need for such stems is relative rare, so only a few glyphs in a typical font are likely to be affected.

We can talk about versioning questions as part of the discussion.

Skef
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec
  _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20240205/4cc7f8eb/attachment.htm>