Re: proposal: second style for quartertone accidentals

[Han-Wen Nienhuys]

Maximilian Albert escreveu:
> For purposes of illustration, I attached a small example of the glyphs
> in (one of) their current preliminary shape(s). Please note that the
> arrowheads of the flat signs are larger (resp. smaller when pointing
> down) than those of the sharp signs because their size is currently
> computed from the width of the stem. But since the design is entirely
> parametrized, it is no problem to change it. I will do that as soon as I
> have a precise idea of their final size.

I think it's best if all arrowheads have the same size.

Also, the brushed stem with the arrowed flat looks awkward. I'd also
try making it straight. 


> 1) Are there any general guidelines or restrictions w.r.t. the overall
> design of the arrows (e.g., regarding size, shape, etc.)? Is it
> sufficient if they are aesthetically pleasing and go well with the usual
> accidental glyphs?

not that I know of. However, all my engraving books are with Jan ATM, so
maybe he can have a look. I suspect that Stone's Notation in the 20th century 
will have some samples.

> 2) I thought about setting the length of the arrow shafts in such a way
> that the arrowheads are placed either completely _between_ two staff
> lines or _on_ the lines, depending on the corresponding position of the
> alteration sign (more or less as in the example). Another possibility is
> to always avoid staff lines, which probably wouldn't look too bad
> either. But then the distances betweeen the accidentals and the
> arrowheads would vary, and the code would have to be adapted so that it
> takes the position of the accidental into account. Opinions?

> 3) How about the size? To increase readability, I think the arrowhead
> should fit completely between two staff lines so that it would be about
> as large as those attached to the sharp signs in the example. But I
> might be wrong. (They seem a bit "invisible" that way when seen from
> further away.)

I think that they should not have variable shapes. Rather, the size should
be small enough to be either entirely in the space (not touching any line).
Also it, should be centered in the space or on the line, so 
its Y position should be rounded to achieve this.

> 4) What do I need to bear in mind during the design w.r.t. collision
> avoidance and similar issues? How do the corresponding algorithms
> determine the overall size of the glyph?

from the bounding box, so set_char_box should produce an accurate box.

> 6) As an aside: When the "test" parameter in the mf/*.mf files is set to
> a  nonzero value, metafont prints staff lines, too (for testing
> purposes). However, I experienced that the arrowhead seemed to touch or
> even cross them in the *.dvi file produced by gftodvi, but after
> compiling lilypond and viewing the pdf output, this turned out not to be
> the case. Is this an inherent problem or can it be fixed somehow?

Probably the line thickness for the test staff doesn't match the one 
that lily uses; the MF code should be adjusted.

> 7) Since I have never used quartertones and other microtones myself: Is
> there a difference between, say, a sharp sign with arrow down and a
> natural sign with arrow up? As far as I understand it, both denote a
> quartertone above the note they are attached to, right? Would it be
> desireable to use both of them simultaneously? (If I am not missing
> something, this might cause a syntax problem when the cascaded approach
> is used.)

This depends. The microtone code doesn't assign any special meaning to 
any glyph, so the user may choose.

>>> The recent microtone improvements needed a much more flexible way to
>>> map pitches onto symbols, and it seems superfluous to have two
>>> mechanisms for setting glyphname at the same time.  It would be
>>> possible  to have a mechanism to set the alist based on the style
>>> property, but I thought it would be overkill.
> 
> Please correct me if I am wrong, but IMHO the "style" syntax is much
> more intuitive and easy to use (in particular for newcomers), especially
> if the final goal is towards a cascaded approach similar to what Jürgen
> proposed. Of course, internally there should be only one _mechanism_ to
> choose the glyphs but I think that being able to set the alists by using
> the style property in the _syntax_ is highly desirable because it
> increases readability of the *.ly files and does not require the user to
> know what happens "under the hood". Of course, strictly speaking, if one
> simply follows the examples in the docs and sets the alists accordingly,
> this doesn't require any further knowledge either, but somehow it
> doesn't _feel_ right to have to do so :). Maybe it is just me.

it would be possible to set a callback on the glyph-name-alist, a callback that
selects a vector depending on the 'style property.  

I don't see a need what cases require cascaded approach for styles.

> Anyway, would you have any objections if I tried some time (whenever
> that may be ...) to think about this idea of using cascades and how it
> could be best implemented?



-- 

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com