>
> > 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.




>

Reply via email to