Klaus Föhl <klaus.fo...@uni-giessen.de> writes: > Hello, > > When changing font in text processing, you switch to a different font, > and most time that's it. Relative placement is taken care of > by the provided font metrics. > > In music notation there is a font, but at least within Lilipond objects > like staves are draws not using glyphs from fonts but more primitive > graphics objects. So I feel one should also change the layout of quite > a few graphical objects when switching fonts. > > I wonder whether one would call that "layout" or "style". > > In the current SMuFL paper (Version 0.4) there are some options: > > use complete notes as provided, or assemble from notehead, stem and flag > ? is there some guidance how to match stem height to flag for > best visual appearance ? > > use complete brackets, or assemble (and combine with a non-font line) > ? What line thickness to go with U+E003 / U+E004 ? > ? Should there be a vertical line in the font with such thickness ? > > use the staves (with the line thickness as provided) or draw lines > While "Scoring programs should draw their own staff lines using primitives" > ? does the font tell you what the line thickness should be ? > > So how to package this ancillary information to go with a "font"?
This question has been a problem essentially forever, even from before computers - clefs and brackets are often engraved separately from notes, etc. Some computer music typesetting software has essentially declared "Everything we print is a character in a font, even staff lines". Other software has gone in other directions. In the context of good typesetting, the answer is "It doesn't really matter, just do the best most efficient job possible." I think, in the context of Lilypond, the best answer is "Package the information in such a way that the creator of a new Lilypond font will be able to understand what he needs to do without having to navigate Lilypond internals or know how the typesetting works". Or, to put it another way, the document "How to Create a Lilypond Music Font" should ideally be short, and able to be understood and successfully applied by someone who knows fonts but doesn't know Lilypond. Right now, such a "font person" tries to make a Lilypond font, gets quite some way into the work, and finds these few lines buried in the documentation: "Step 893: Re-write Lilypond to accommodate what you've created in the preceding 892 steps. This step is left as an exercise for the reader." "Step 894: If you are religious, you should take some time to pray now. Even if you're not religious, praying is still recommended, just in case." "Step 895: I thought that might happen. Too bad. Oh well, go back to Step 1 and let's try to see what went wrong." :) I have no illusion that making a font for Lilypond should be easy. I _do_ have the illusion that it ought to be a clearly-defined task.* If, in Lilypond's case, "Font" means more than it does in other situations (for example, if for Lilypond a font designer must provide a lot of additional measurements or extra glyphs), well, so be it. As long as he's told what the requirements are, and how to ensure that his new font will actually work. * - It's easy to see that the history of Lilypond development might have meant that at one time there was a lot of pressure to "get it working" and very little pressure or desire to "get it ready for different music fonts". -- David R _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user