Re: RFC on MR 1368

[Luca Fascione]

I've read a bit of the discussion.
I'll share my thoughts, I hope they can be of some use.

TLDR: I like Werner's approach best, as conceptually outlined in his
comment at 'May 25, 2022 6:02am GMT+0200' (*)
Largely because it seems to me it lines up best with the sequence of
activities somebody working on this data is likely to do often.

(*) is there really no way to cross reference/link a commit comment from
gitlab? gah.

However I don't think what conclusion I came to matters much, I feel I can
provide more value to the discussion
explaining how it is that I came up with it.

Which is what follows:

The issue at hand seems to be whether it makes sense to have one file per
font versus several files per font,
and in case the answer is the latter, what goes in these files. If I
understand Jonas right, he sees it as important to have
all data grouped by 'item' (in this case, by glyph): I hear him as seeking
a view where all values/settings pertaining to a given
glyph is reliably found in the same file.

Werner instead wants all outlines in one file, all kerning info in a
separate file, all OT features in their own file and so on.

It seems to me in this case anyone that would need to work (ie make changes
on the font on a regular basis) would have no trouble
with either layout, because I feel this statement is correct:

if one's job was to make alterations to Emmentaler, it would take them
reading a couple lines of text to build a
mental model of where to find the data they're after and it's a simple
model to keep straight in one's head.


I felt bold enough to go ahead and separate it out because I think that
this is the key issue. In different words: I am in the middle of altering a
glyph,
and it occurs to me this change also affects the kerning tables, how
distracting/disruptive is it for me to locate the kerning tables and make
the change?

The answer that works best for that question is: the disruption must be
inversely related to how common the scenario is.

In other words: if this happens all the time (every time you touch one CV
by a hair, you need to touch all the kerning pairs that include the glyph
immediately),
then that disruption should be tiny (you _can_ achieve this with keeping
the data in the same file, but you can also achieve it with editors that
help you keep
several things aligned and ready to take your edits, for example). On the
other hand, if the scenario is rare, you can definitely tolerate larger
disruptions, reclaiming
useful "space" for your workflow design where you'd fit the support for
more common scenarios. And this 'larger' amount of disruption you have to
work with, grows quickly: it feels like
what people would normally call "exponential", which is probably more like
"quadratic" IRL (something half as likely can introduce 4 times as much
disruption).

And this is where I _completely_ agree with Han-Wen: that the thing one
must do in these circumstances is to listen to expert users that have many
hours
of this activity under their belt. It doesn't necessarily mean to just do
the first thing they say, but it does mean that it is not admissible to
discount evidence
coming from their actual experience. Mind you, this does on occasion
include conceiving different solution from what they might have devised so
far.

In the matter at hand Werner is obviously a very proficient software
engineer, and there is no doubt he understands the engineering tradeoffs of
his proposals,
both in how they affect his own situation, as well as how they would affect
others carrying out the same task. In a different scenario, where you'd be
working with
less technical users, you'd want to work on explaining some of these things
to them, so you come to agree to a satisfactory way forward, while including
them in the design process of the solution.

I want to go back to the scenario I outlined at first as an example. I
said: "I am in the middle of altering a glyph, it occurs to me this also
affects the kerning tables".
I think the idea that altering glyphs and instantly turning around and
revising kerning tables is just not a workflow that people want to use.
It would be my expectation (*) that in fact what you want to do as a
designer is go in waves where first you focus on CV positioning and shapes,
and then you do scans and fix kerning pairs, and so on in "passes". It
lines up with how people work in a lot of fields that share similarities
with this activity, too.

(*) I feel I see a shadow of this in the story I read from Werner's
comments as well, but I'll admit it's also possible this is just
confirmation bias

The other thing that is very weird about this is just that the counts work
in strong favour of Werner's idea (which again speaks to his experience on
the ground):
 - glyphs files are O(n) objects
 - kerning tables are O(n^2) objects (they're "all" the pairs of glyphs)
 - OT feature tables are kinda O(1) objects, with a constant that is
probably glyphcount ;) seriously though: I feel they are O(1) objects
because they effectively never change, in a time-derivative sense

Think about a task where you're adjusting serifs (maybe you're making a
slab serif variant of a sans font):
 1- you'd touch all glyphs at least once (change n glyphs)
 2- you'd touch all the kerning tables (change n^2 pairs)
 3- OT feature tables are probably fine as they are

I'd imagine that first you'd pick a whole bunch of glyphs, and goof about
with their CV's for hours on end,
then you'd render out all the pairs you'd need to inspect manually and
apply kerning adjustments, and that's another several-hour task
then maybe you spend 5 minutes because there's a bug in the features table.

To me, this screams as three separate file types.

Besides, working as a large team, I can imagine myself as someone that
could meaningfully contribute to 2 and 3, but I'd have no idea what to do
about 1.
So I would feel a lot safer if my changes and tests didn't risk to
invalidate or overlap with work from the outline designer.
And they may have interest in working on CV's and kerning tables, but maybe
are not that interested in the technicalities of feature table setup.

And these are the reasons why at this point it seems to me Werner's
approach fits the workflow of the users better than Jonas's proposal.

HTH,
L

PS: One thing that I find really distracting is all these python files
everywhere, if it is true these are just tables of hand-authored data,
I would personally find it easier to wrap my head around to have a data
format for them. But I think for what concerns the essence of this
discussion this is just a tangent.


On Wed, May 25, 2022 at 8:39 AM Han-Wen Nienhuys <hanwenn@gmail.com> wrote:

> I have had many similarly exhausting discussions before, so I
> empathize (it is also the reason that I paused my contributions
> recently.)
>
> I would go with Werner's choices here; as the Freetype author, he is
> the expert on font features and technology.
>
> From the MR:
>
> > I equally object to any contribution being merged "because the author
> knows what he's doing".
>
> I object to reviewers blocking contributions just because they have a
> strong opinion on how things should be done. In this case, Jonas has
> made 0 contributions to the MF code, so I don't think his concerns
> should be overriding.
>
> If Jonas feels really strongly about how the kerning should be
> handled, I invite him to teach himself the joys of Metafont and try
> his hand at a follow-up MR.
>
> On Wed, May 25, 2022 at 12:01 AM Werner LEMBERG <wl@gnu.org> wrote:
> >
> >
> > Folks,
> >
> >
> > Jonas and I have an intense (and very exhausting) discussion where to
> > add kerning data.  I want to hear more opinions whether I should go
> > 'route one' (which I prefer) or 'route two' (which Jonas prefers).
> >
> > Please have a look at MR 1368
> >
> >   https://gitlab.com/lilypond/lilypond/-/merge_requests/1368
> >
> > and chime in.
> >
> >
> >     Werner
> >
>
>
> --
> Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
>
>

-- 
Luca Fascione