Freeman Gilmore wrote > Say I was going to create the glyph “#” for the first > time.
What exactly do you mean by "create the glyph"? The glyph is contained in the music font, and as most of the music glyphs, it doesn't even have a fixed character code and even move around when new glyphs are being added in later releases. Therefore, they have to be accessed by their names. The naming conventions just help to get them organized in a way. By the way: even "ordinary" PostScript fonts do have glyph names that may differ from what you actually type. For example, "5" ist named "five" or "!" is named "exclam". Freeman Gilmore wrote > Using the naming convention I name it “accidentals.sharp” (if this > is the complete name?). BUT I would use the name (or one of it equals) > “…is” to print “#...”? * The point is that in everyday LilyPond usage, you do not need to know or enter the glyph name at all. And, by the way a sharp accidental is not a # (number sign). LilyPond interprets your code and generates output from it. When you write "fis", for instance, this will produce a notehead (the specific notehead glyph depends on the duration) plus (eventually) a sharp accidental in front of it. In the key of G major, however, it will not print a sharp accidental, because it's contained in the key signature. In addition to that, depending on the duration, the note will have a stem (or not). This stem may have different lengths depending on the circumstances. This stem may have different directions. The stem may have a flag (different flag glyphs depending on the duration). Or it may be beamed (depending on the neighbouring notes an the beat structure and its position within the measure). As you can see, a simple "fis" entry may produce many different glyphs. This all happens without having to know a single glyph name. Extreme example: in guitar tablature, a "fis" will be a fret number on a string. Freeman Gilmore wrote > *Why two names?* It's not two names, it's a code being interpreted for producing a complex combination of glyphs and graphical elements. These single elements may be glyphs of a font using internal glyph names. There is, however, one notable exception: if needed, every single music glyph can be accessed by its name in a markup text. \markup \line { In older prints, a quarter rest \musicglyph "rests.2" often looks like \musicglyph "rests.2classical" } <http://lilypond.1069038.n5.nabble.com/file/t3887/markup-musicglyph.png> Freeman Gilmore wrote > *What convention is used for the second name (not a part of mf/readme); > this is the one I am more interested in?* I guess by "second name" you mean the "...is" suffix. But this is not a glyph name but part of a note name that will be converted into one or more glyphs at certain positions. By the way, LilyPond allows note names to be entered using several languages. But a Dutch or German fis will produce exactly the same glyphs as an English fs or f-sharp or a French fad (fa dièse) --- all will produce the same output. So, depending on the input language used, one and the same note may have different names. Even more importantly, even within one language, all the different note names (c, d, e, f, g, a, ...) will use the same glyphs (in different stave positions, though) and depending on their duration, a "c" may have many different noteheads (i.e. notehead glyphs), may have a stem or not, may one of different flags (i.e. flag glyphs) or not, may be beamed, etc. As you can see, a "fis" may look different depending on the surrounding circumstances. Generally, any markup language will interpret contents and syntax and produce an output from it. There is no simple 1:1 relationship between text code input and the actual output. In C major, the first fis in a bar will get a sharp accidental, but the next one won't get an accidental. This is important for several reasons. Just imagine you'd have to code every single glyph used instead of entering meaning and contents, i.e. music. Then it'd be virtually impossible to transpose or play back the music. All the best, Torsten -- Sent from: http://lilypond.1069038.n5.nabble.com/User-f3.html _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user