<div dir="auto">Hi<div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">If we are going to change it, don't think 2 words is going to stick. "Sources", perhaps. </div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto">Dave</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2024, 11:36 PM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>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.</p>
<p>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. <br>
</p>
<p>(A single word would be easier but those tend to be taken one or
twice over at this late date.)<br>
</p>
<p>Skef <br>
</p>
<div>On 2/5/24 13:32, Hin-Tak Leung wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px">
<div>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?</div>
<div><br>
</div>
<div>"primary/primaries" probably can work? "primary source
data"? "Source primary"?</div>
<div><br>
</div>
<div id="m_711922894709741043ydp344c07a4yahoo_quoted_7998069860">
<div style="font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:13px;color:#26282a">
<div> On Monday, 5 February 2024 at 21:04:50 GMT, Thomas
Phinney <a href="mailto:tphinney@cal.berkeley.edu" target="_blank" rel="noreferrer"><tphinney@cal.berkeley.edu></a> wrote: </div>
<div><br>
</div>
<div><br>
</div>
<div>
<div id="m_711922894709741043ydp344c07a4yiv6692309986">
<div>
<div dir="ltr">
<div style="font-family:verdana,sans-serif;font-size:small">IIRC,
we had a (very lengthy!) discussion of this same
issue internally at FontLab back when I was CEO.</div>
<div style="font-family:verdana,sans-serif;font-size:small"><br clear="none">
</div>
<div style="font-family:verdana,sans-serif;font-size:small">We
never came up with an alternate word that seemed
workable for the font data concept. “Main” really
does seem <i>singular</i> in a way that “master”
is not necessarily.</div>
<div style="font-family:verdana,sans-serif;font-size:small"><br clear="none">
</div>
<div style="font-family:verdana,sans-serif;font-size:small">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.</div>
<div style="font-family:verdana,sans-serif;font-size:small"><br clear="none">
</div>
<div style="font-family:verdana,sans-serif;font-size:small"><br clear="none">
</div>
<div style="font-family:verdana,sans-serif;font-size:small"><br clear="none">
</div>
</div>
<br clear="none">
<div>
<div id="m_711922894709741043ydp344c07a4yiv6692309986yqt72332">
<div dir="ltr">On
Mon, Feb 5, 2024 at 12:53 PM Hin-Tak Leung via
mpeg-otspec <<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a>>
wrote:<br clear="none">
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="font-family:Helvetica,Arial,sans-serif;font-size:16px">
<div>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.</div>
<div><br clear="none">
</div>
<div>Maybe the opentype spec should avoid
the word "master" for that reason too.</div>
<div><br clear="none">
</div>
<div id="m_711922894709741043ydp344c07a4yiv6692309986m_-641728661922181094ydp987cb2bcyahoo_quoted_7521758938">
<div style="font-family:Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
<div> On Monday, 5 February 2024 at
20:44:15 GMT, Peter Constable via
mpeg-otspec <<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a>>
wrote: </div>
<div><br clear="none">
</div>
<div><br clear="none">
</div>
<div>
<div dir="ltr">Hi, Skef<br clear="none">
<br clear="none">
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. <br clear="none">
<br clear="none">
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.<br clear="none">
<br clear="none">
<br clear="none">
A question about this: I gather that
this would require changes in CFF2
rasterizers?<br clear="none">
<br clear="none">
<br clear="none">
Peter<br clear="none">
<div id="m_711922894709741043ydp344c07a4yiv6692309986m_-641728661922181094ydp987cb2bcyqtfd48815"><br clear="none">
-----Original Message-----<br clear="none">
From: mpeg-otspec <<a shape="rect" href="mailto:mpeg-otspec-bounces@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec-bounces@lists.aau.at</a>>
On Behalf Of Skef Iterum via
mpeg-otspec<br clear="none">
Sent: Monday, February 5, 2024
3:23 AM<br clear="none">
To: <a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a><br clear="none">
Subject: [EXTERNAL] [MPEG-OTSPEC]
Relaxation of CFF2 hint
requirements (?) in variable fonts<br clear="none">
<br clear="none">
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.<br clear="none">
<br clear="none">
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.<br clear="none">
<br clear="none">
We can talk about versioning
questions as part of the
discussion.<br clear="none">
<br clear="none">
Skef<br clear="none">
_______________________________________________<br clear="none">
mpeg-otspec mailing list<br clear="none">
<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a><br clear="none">
<a shape="rect" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="nofollow noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br clear="none">
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br clear="none">
mpeg-otspec mailing list<br clear="none">
<a shape="rect" href="mailto:mpeg-otspec@lists.aau.at" rel="nofollow noreferrer" target="_blank">mpeg-otspec@lists.aau.at</a><br clear="none">
<a shape="rect" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="nofollow noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br clear="none">
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" rel="noreferrer">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>