Federico Bruni <[email protected]> writes: > Il 02/01/2013 09:52, David Kastrup ha scritto: >> Federico Bruni<[email protected]> writes: >> >>> It took me some time to understand the following: >>> >>> \version "2.17.10" >>> >>> \relative c'' { >>> \footnote #'(2 . 4) "Footnote 1"<d-3>2 % it's not printed because >>> of the<> >>> \footnote #'(2 . 4) "Footnote 2" Stem<d-3> % unless I specify Stem >>> } >>> >>> IIUC, the grob-name *must* be specified when a footnote is attached to >>> a note enclosed in a chord construct. >> >> Uh, no? >> >> \relative c'' { >> <\footnote #'(2 . 4) "Footnote 1" d-3>2 >> } >> >> works just fine. >> > > Ooops, this option didn't come to my mind. > >>> I'm reading NR 3.2.3 and in particular: >>> >>> """ >>> Marking an entire chord in this manner is not possible since a chord >>> does not produce an event separate from that of its chord >>> constituents, but the constituents themselves can be marked. >>> >>> If the layout object being footmarked is indirectly caused by an event >>> (like an Accidental or Stem caused by a NoteHead), an additional >>> symbol argument, the grob-name, is required before the footnote text: >>> """ >>> >>> I'm not sure if this fully explain the "problem". >>> What do you think? >> >> In the light of the above example working just fine, could you explain >> how one should have written the NR so that you would have been able to >> achieve what you wanted? >> > > A simple warning saying that \footnote must be used inside a chord > construct would have helped. I wouldn't give it for granted.
Exactly this has been said in the passage you quoted above: >>> Marking an entire chord in this manner is not possible since a chord >>> does not produce an event separate from that of its chord >>> constituents, but the constituents themselves can be marked. Since you repeat your complaint after quoting the text, and even after we had this brief discussion (which a reader of the manual will _not_ have at his disposal), it is obvious that this passage has been written in a manner that fails to make readers realize its actual meaning. Could you propose a replacement for this paragraph that might have worked better for you? It is not enough that you may find yourself able to grasp its meaning after a back-and-forth discussion: the average manual reader will not have this luxury at his disposal, or at least if he has, we'd like it to be used on questions that are not supposedly already answered in the manual. If the text is not sufficiently obvious in the English text, the situation will likely get even worse in the translations. So we really want to get the English text straightforward to the degree of being blunt. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
