Hi everyone, motivated by Orm's proposal to make arrowed accidental glyphs available, I have started a few experiments with the feta mf-sources. They seem to be quite promising, and I think that we will soon be able to provide the "arrowed" style as an alternative -- for a suitable meaning of "soon", though, since Orm and I are both rather busy at the moment.
However, in the process of playing around there have arisen a few questions. They are currently mostly with regard to the actual glyph design (I haven't tampered much with the engraving code yet). 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. Here are my questions: 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? 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.) 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? 5) Another related thought: It is probably not too hard to adapt the code so that the length of the arrow shaft is not fixed but can be increased or decreased arbitrarily "on the fly". This might be used by other code to avoid collisions. But I have the feeling that this as unnecessary and would be an overkill. Agree? 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? Well, I think that's it for now. I have a few more questions in mind regarding Jürgen's proposal of including "layers" or "cascades" of styles but I think they will need a bit more time to crystallize out. Only one further question for now: 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.) Oh, and another thing regarding Han-Wen's recent reply to one of my emails: >> 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. 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? Thanks a lot for reading all this, as well as for any answers or hints. Best wishes, Max
arrowed_accidentals.pdf
Description: Adobe PDF document
_______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
