> > > This addition does not involve any development. All the stuff is already > > developed. Just simply, AFAIK, add the fonts to their respective > > directories, as I have already done. > > Here are some things to consider: > > * You point to modern printers generating thinner lines. However, the > design objective of Feta was to mimic plate engraving with thicker > lines. In that sense it is working as intended, even if it is not your > preferred style. > > I don't think so.
I'm sorry if I can seem overly punctilious, pedantic and unpleasant (and I repeat that these are my * personal * observations), but look at this score: https://ks.imslp.net/files/imglnks/usimg/0/0c/IMSLP521885-PMLP2394-Debussy_Claude-Pr%C3%A9ludes_1er_Livre_Durand_7687_scan.pdf The lines are thick and it's plate engraving dated 1902! The numerator and the denominator of the time signature are bold enough for these thicknesses but never overlap, unlike Feta. See also the trill glyph on page 44. You can notice that Feta has too thin curves combined with too thick curves, while in Debussy's score all the trill curves are modeled on a more or less uniform thickness, consistent with the thickness of the lines. > (I do accept the blame for the font being a haphazard collection of > individual glyphs I happened to like, rather than a coherent > ensemble.) > > * LilyPond is built from source. Although rare, it does happen that we > tweak glyphs (for example, see the work that Owen Taylor is doing for > Smufl support). This process doesn't work well with Gonville, as it > is not generated with Metafont. How do you envision development > happening with Gonville as a standard font? > > This is not a problem. Just leave Feta as a native font and insert a dummy wrapper for Gonville in the ./configure. This does not require any development, nor uniformity in the coding standard and can be easily added to the source tree. Using a flag like --with-gonville-font you can also be sure that if the Gonville src is not aligned with the source of Lilypond, the compilation will give an error. At this point the user will be able to remove the flag and continue compiling. There are many similar examples. For example x264 is not a native codec for ffMPEG, but it is the * de facto * codec for it and is added to the project via a simple wrapper. (politically correct Disclaimer ;-) ): Before anyone gets annoyed by all these considerations, I repeat that I am all personal opinions, without wanting to convince anyone but it is my goal only to invite to meditate on the subject. And in particular they are determined by the fact that, from what I have observed, the work on Gonville is truly impressive and meticulous. I think anyone can observe these details. >