[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [2.20] Issue 4943 Manual page breaking causing assertion failure usi

From: Thomas Morley
Subject: Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows
Date: Wed, 4 Jan 2017 15:25:56 +0100

2017-01-04 14:26 GMT+01:00 Chris Yate <address@hidden>:
> On Wed, 4 Jan 2017 at 12:39 Thomas Morley <address@hidden> wrote:
>> 2017-01-04 11:11 GMT+01:00 Chris Yate <address@hidden>:
>> > 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."



reply via email to

[Prev in Thread] Current Thread [Next in Thread]