[MPEG-OTSPEC] [EXTERNAL] Re: "master" terminology
Skef Iterum
skef at skef.org
Mon Mar 11 21:49:27 CET 2024
I thought by the context of what I was responding to that it would be
clear I was offering another alternative to "master", which some people
(regardless of etymology, see GitHub) may want to change. Note that I
don't have strong opinions on that either way; I didn't bring it up.
As far as my use of that term in the document that started this thread,
I had already changed that before the last meeting, as I noted on the
list in a different message.
Skef
On 3/11/24 13:07, Peter Constable wrote:
>
> Skef:
>
> It’s not clear to me in what context you’re suggesting new
> terminology. You had used it in your doc on CFF2 stem hints in a way
> that appeared to mean any runtime-selectable variation of the font.
> The OT and OFF specs already use the terminology “design-variation
> instance”, “design instance”, “variation instance” or simply
> “instance” for that meaning. The things listed in the ‘fvar’ table are
> already referred to as “named instances”, both in the spec and in
> common parlance. And, as I pointed out earlier, “master” is defined in
> the spec as having to do with source data in a font development
> workflow— I don’t think that’s inconsistent with what Dave has said.
>
> *Font face:* A logical collection of glyph data sharing specific
> design parameters, along with associated metric data, and names or
> other metadata.
>
> *Variation instance:* A font face corresponding to a particular
> position within the variation space of a variable font.
>
> *Named instance:* A variation instance that is specifically defined
> and assigned a name within the 'fvar' table.
>
> *Master:* A set of source font data that includes complete outline
> data for a particular font face, used in a font-development workflow.
>
> (See Terminology
> <https://learn.microsoft.com/en-us/typography/opentype/spec/otvaroverview#terminology>.)
>
> Peter
>
> *From:*mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> *On Behalf Of
> *Dave Crossland via mpeg-otspec
> *Sent:* Sunday, March 10, 2024 10:52 PM
> *To:* Skef Iterum <skef at skef.org>
> *Cc:* mpeg-otspec <mpeg-otspec at lists.aau.at>
> *Subject:* [EXTERNAL] Re: [MPEG-OTSPEC] "master" terminology
>
> 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> <mailto: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/20240311/7f4a3901/attachment-0001.htm>
More information about the mpeg-otspec
mailing list