Il giorno sab 5 ott 2019 alle ore 16:29 Urs Liska <li...@openlilylib.org> ha scritto: > thank you for looking into it. Unfortunately I don't really see how that > works from the diff.
Both internalBarNumber and currentBarNumber (the printed one) are stored as context properties in the Score context. With the current LilyPond, PaperColumn and NonMusicalPaperColumn grobs have the rhythmic-location property, which, as you know, stores the pair (internalBarNumber . measurePosition). My patch simply adds a printed-rhythmic-location property to those grobs, storing the pair (currentBarNumber . measurePosition), and a corresponding grob::printed-rhythmic-location procedure. > Does David's comment suggest that it would be possible to keep track of the > barnumber difference through a Scheme engraver? Or is this some information > that already gets lost in the C++ code, so it would require an update to > LilyPond itself? Given that the information is available as a context property, I understand from David's comment that a Scheme engraver should suffice, but I have no experience in writing engravers. However, I think that the current bar number (as seen by the player) is such a basic kind of information that having it directly available as a grob property warrants this small addition to LilyPond (unless there are any drawbacks I am not considering). Best wishes. Davide _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
