[MPEG-OTSPEC] "master" terminology

[Dave Crossland]

Hi

Personally I am all for changing master/slave naming to primary/secondary,
but master is not only contrasted with slave. I have a master's degree. My
father was a ship's master. Chess players are masterminds.

Mastering is a process in music production, and this is where the word
comes to font production from, in my opinion. I don't see this use in
opentype as similar at all to say database replication.

If we are going to change it, don't think 2 words is going to stick.
"Sources", perhaps.

Cheers
Dave

On Sun, Mar 10, 2024, 11:36 PM Skef Iterum via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> 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> <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
>
> _______________________________________________
> 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/e5c7ea41/attachment.htm>