[MPEG-OTSPEC] "master" terminology

[Skef Iterum]

Had a shower thought this evening: What about "design instance"? And 
then calling what is the list in fvar, when there is a need to 
differentiate, a "user instance"? This would be, in effect, extending 
the distinction between design coordinates and user coordinates to 
instances.

One thing I like about this is that it doesn't carry the heavy weight 
connotation that "master" seems to, in that it seems natural to talk 
about the "design instance" of a whole font or of a single glyph, while 
using "master" for the latter doesn't seem quite right.

(A single word would be easier but those tend to be taken one or twice 
over at this late date.)

Skef

On 2/5/24 13:32, Hin-Tak Leung wrote:
> 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/pipermail/mpeg-otspec/attachments/20240310/f8ec964d/attachment-0001.htm>