Re: naming a glyph

[Torsten Hämmerle]

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