Re: RFC on MR 1368
On 5/25/2022 4:16 PM, David Kastrup wrote: I cannot do much more than express my gratitude that I see people willing to work on addressing one another's concerns and wish them success doing it without wasting unnecessary amounts of their energy. Same here. The font-structure issues have multiple overlapping technical topics far beyond any capacities I have for engaging with them. All parties in the discussion have my respect for what they have contributed to LilyPond. Disagreement is relationally expensive, and its costs must be managed. But sometimes working through it is necessary to reach better understandings of an issue. -- Karlin High Missouri, USA
Re: RFC on MR 1368
Jean Abou Samra writes: > I agree that all commits should have a clearly explained and > duly justified rationale, because a review is a request > from the developer community to accept to collectively > build upon and maintain new code, and to invite future > developers to do so. On the other hand, I feel like a > lot of this particular discussion has been Werner explaining > background knowledge on the tooling (Metafont and FontForge > and their issues). Font-related programming is a discipline in > itself. I think commit messages, MR summaries and code comments > should aim to provide motivation for the change and the design in > a language targeted for a reader who does know about the context, > or there would be no end to it. > > You are the one who does most review on code areas you > are not primarily a specialist of, which I very much > appreciate from experience on my own MRs, as it does catch > smaller or bigger problems or gives perspectives that I > hadn't thought of. However, on areas that it takes months > or years to become an expert of (LilyPond has a number > of those), trusting the judgement of someone who took > that time is a necessity. Well, the one thing we cannot trust anybody with is to be immortal in relation to the project (and even outside). We would not want to paint us into the kind of corner that I view Guile in, being absolutely dependent on one person to maintain their code developed and contributed without a perspective of others joining or continuing the work. We want to avoid the wasted time of someone picking up the baton later and trying for months to move the code into the obvious direction, only to finally fail at the point that the person previously working on the code circumnavigated with good reason. Conflict resolution on the mailing list is a mostly manual process, and as opposed to arguing with a computer until it accepts the results of a series of imperfect attempts, human enthusiasm and patience is not an unexhaustible resource. So a lack of acumen cannot really be offset by sufficient tenacity, as opposed to working with computers. It's good to keep this in mind and try focusing on figuring out the differences one is having with others sufficiently so that one feels confident making progress towards a resolution with each communication. This thread is more or less inviting outside opinion, and it ended up more in a discussion about trust than content because regarding the content, the knowledge is not all that widely distributed. Now with regard to conflict resolution, I feel a bit like a celibate person feeling compelled into giving marriage advice. I cannot do much more than express my gratitude that I see people willing to work on addressing one another's concerns and wish them success doing it without wasting unnecessary amounts of their energy. Sorry for that heap of platitudes in lieu of an opinion. -- David Kastrup
Re: RFC on MR 1368
This discussion isn't exactly putting Jonas in a comfortable situation, which I empathize with, and I'm trying not to add to that. I do want to raise a few points. Le 25/05/2022 à 19:05, Jonas Hahnfeld via Discussions on LilyPond development a écrit : From the MR: I equally object to any contribution being merged "because the author knows what he's doing". For context, this was in response to "I hope that you can trust me, being the FreeType maintainer since 20 years, on font issues." which, during code review, makes it far too easy to dismiss arguments without the needed explanations for "mere mortals". I agree that all commits should have a clearly explained and duly justified rationale, because a review is a request from the developer community to accept to collectively build upon and maintain new code, and to invite future developers to do so. On the other hand, I feel like a lot of this particular discussion has been Werner explaining background knowledge on the tooling (Metafont and FontForge and their issues). Font-related programming is a discipline in itself. I think commit messages, MR summaries and code comments should aim to provide motivation for the change and the design in a language targeted for a reader who does know about the context, or there would be no end to it. You are the one who does most review on code areas you are not primarily a specialist of, which I very much appreciate from experience on my own MRs, as it does catch smaller or bigger problems or gives perspectives that I hadn't thought of. However, on areas that it takes months or years to become an expert of (LilyPond has a number of those), trusting the judgement of someone who took that time is a necessity. [Carl] I think it is important for us to recognize that Jonas has not been asking for authority to reject a patch. He has been expressing technical concerns about the selected architecture. Code review should allow for this kind of expression in all cases. I hope we can recognize that both Werner and Jonas are trying to improve LilyPond. And in fact, Werner has indicated that he needs to make changes in response to Jonas's questions. +1 All the best, Jean
Re: RFC on MR 1368
On Wed, May 25, 2022 at 11:20 AM Kevin Barry wrote: > > Also technically I cannot "block contributions", nobody in the > > community has the power to do so. > > > > This might be true technically, but in practice your objections are usually > enough. > I think it is important for us to recognize that Jonas has not been asking for authority to reject a patch. He has been expressing technical concerns about the selected architecture. Code review should allow for this kind of expression in all cases. I hope we can recognize that both Werner and Jonas are trying to improve LilyPond. And in fact, Werner has indicated that he needs to make changes in response to Jonas's questions. Thanks, Carl
Re: RFC on MR 1368
> Also technically I cannot "block contributions", nobody in the > community has the power to do so. > This might be true technically, but in practice your objections are usually enough.
Re: RFC on MR 1368
On Wed, 2022-05-25 at 08:02 +0200, Han-Wen Nienhuys 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". > For context, this was in response to "I hope that you can trust me, being the FreeType maintainer since 20 years, on font issues." which, during code review, makes it far too easy to dismiss arguments without the needed explanations for "mere mortals". > 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. I'm very sorry that I didn't know this was required to make comments on merge requests... Also technically I cannot "block contributions", nobody in the community has the power to do so. I will, however, point out any problems in the design or code that I feel worth mentioning. I don't care if this makes me "likable" or not. I always give technical arguments to explain my point of view, and that's how I think code review should work in an open source community. > 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. (FWIW this is not how I think reviews should work) signature.asc Description: This is a digitally signed message part
Re: RFC on MR 1368
There! Thanks Aaron! L On Wed, 25 May 2022, 15:34 Aaron Hill, wrote: > On 2022-05-25 1:31 am, Luca Fascione wrote: > > (*) is there really no way to cross reference/link a commit comment > > from > > gitlab? gah. > > The post's relative time (e.g. "9 hours ago") should itself be a > hyperlink with the appropriate named anchor: > > [1]: > https://gitlab.com/lilypond/lilypond/-/merge_requests/1368#note_959007386 > > > -- Aaron Hill >
Re: RFC on MR 1368
On Tue, May 24, 2022 at 4:01 PM Werner LEMBERG 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. > I've chimed in on the merge request comment chain. I think we should approve the patch as long as it functions correctly. While both of the proposed architectures can probably be made to work, it's not clear that Werner's actual archictecture is worse than Jonas's proposed architecture. So in my mind we should take the existing functional patch. Carl
Re: RFC on MR 1368
On 2022-05-25 1:31 am, Luca Fascione wrote: (*) is there really no way to cross reference/link a commit comment from gitlab? gah. The post's relative time (e.g. "9 hours ago") should itself be a hyperlink with the appropriate named anchor: [1]: https://gitlab.com/lilypond/lilypond/-/merge_requests/1368#note_959007386 -- Aaron Hill
Re: RFC on MR 1368
> 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. This is not correct. I would *love* to be able to have everything in `.mf` files if it made sense. However, it doesn't. As mentioned in the very beginning of the discussion in the MR, we have IMHO to demote Metafont's use (or rather, MetaPost) to a mere outline and metrics generator because of technical constraints of this old software. It thus becomes just one component in the stream of tools necessary to build the fonts. ``` mf2pt1 Metafont source files (.mf) -> FontForge (via mf2pt1) raw Type 1 fonts -> (hinted) Type 1 fonts, with outline intersections removed and outlines simplified (.pfb) ``` The next step is font merging to create OpenType fonts. ``` FontForge *.pfb > *.otf ``` After this, the font should be enriched with kerning and OpenType features. ``` FontForge Kerning data (.py) > add 'GPOS' OpenType table to font FontFOrge Feature data (.py) > add 'GSUB' OpenType table to font ``` Note that FontForge could be replaced with other, similar tools like Adobe's Font Toolkit. > 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? In normal font editing with Metafont, the problem doesn't exist at all. The reason is that there is no means to visualize the kerning! Instead, you have to generate the font, then processing, say, a small TeX program that generates visual representations of kerning pairs, look at them, adjust the kern value, recompute the font, recompute the representation, etc., etc. Contrary to TeX, there don't exist comfortable IDEs for editing fonts created with MetaFont. And I'm 100% sure that this won't ever happen. > 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". It rarely does, as far as I can say. > 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. Correct, but your mileage may vary. In FontForge, for example, there is a special window to display kerning pairs and to adjust kerning values. Note that while kerning data is stored in a font, it isn't associated at all with the glyphs. They are separate. Even in the old days of Type1 fonts, kerning was separate (in the `.afm` file). > 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. The native language of almost all professional font manipulation tools is Python; it is thus very natural for most font developers if the corresponding scripts use this programming language. Werner
Re: RFC on MR 1368
On Wed, 25 May 2022 at 07:38, Han-Wen Nienhuys wrote: > > 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. > I agree with this. We should accept Werner's change. And, more generally, I think we should err on the side of accepting contributions. Kevin
Re: RFC on MR 1368
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
Re: RFC on MR 1368
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 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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
RFC on MR 1368
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
