2017-01-04 14:26 GMT+01:00 Chris Yate <chrisy...@gmail.com>: > > On Wed, 4 Jan 2017 at 12:39 Thomas Morley <thomasmorle...@gmail.com> wrote: >> >> 2017-01-04 11:11 GMT+01:00 Chris Yate <chrisy...@gmail.com>: >> >> > I'm not quite sure what you want me to test, but, here's what I've >> > tried. >> [...] >> >> Hi Chris, >> >> sorry not been clear enough. >> Many thanks for your testings though. >> >> I've now created the attached test-file (and the pdf I get [*]) >> >> Please uncomment the test-scores one by one. >> >> I'd expect test 1 and test 1a to work >> Not sure with test 2 and test 2a >> test 3 and test 3 will likely fail with assertion. >> >> How does it work for you? >> >> Cheers, >> Harm > > > Hi, > > I ran these tests individually and together. All succeed and none throw the > assertion failure! > > I've attached the PDF.
Hi Chris, I'm somewhat surprised it's all working for you. (Your pdf only shows test 1/1a) myAutoBreaksOn/Off is not that different from the content of your Defs1.ily Are you sure all works? Anyway, myAutoBreaksOn/Off omits every overrideProperty, with the consequence the relevant command takes effect one step later than most would expect! (In test 3 and 4 it's always R1/femataMarkup on next line not the simple R1) So, in the the current situation overrideProperty will cause an assertion failure on windows while used in autoBreaksOn/Off. Likely the underlaying problem persists for a long time... A proper fix would involve some (probably very deep) C++-work, far beyond my depth. Would it be reasonable to reduce the intended use-cases by deleting those \overrideProperty settings from all auto-break-settings and document the behaviour of the remaining usability? At least we did something similiar with associatedVoice. >From NR "Note: The set associatedVoice command must be placed one syllable before the one at which the switch to the new voice is to occur. In other words, changing the associated Voice happens one syllable later than expected. This is for technical reasons, and it is not a bug." Opinions? Cheers, Harm _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
