Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #316754: Empty rehearsal mark not deleted after entering a line break #7396

Merged
merged 1 commit into from
Feb 3, 2021

Conversation

mattmcclinch
Copy link
Contributor

@mattmcclinch mattmcclinch commented Feb 3, 2021

Resolves: https://musescore.org/en/node/316754.

When #4359 attempted to fix https://musescore.org/en/node/278068 (and was shortly followed up by #4364), the end result was that when a newline is inserted into a text block (causing it to split into two text blocks), the second text block would always end with a newline, even if the original text block did not. This is fixed here by setting the second text block's EOL flag to that of the original text block.

This is what is attempted by the function that joins two text blocks when a newline is deleted, but that function wasn't getting it right either. So that has been corrected here as well.

Taken together, these two errors meant that there would be a blank line at the end of any text element that had ever contained a newline. This blank line would be small, but it would always be present, even if you tried to delete it.

Because this blank was always present in multiline text elements, and because it was small enough to not attract much attention, #5881 only added an empty text fragment before a newline, and not after. But now that we do not have to have unwanted newline characters, in order to preserve the font size on a blank line, an empty text fragment may be needed after a newline also.

…reak

Resolves: https://musescore.org/en/node/315754.

When musescore#4359 attempted to fix https://musescore.org/en/node/278068 (and was shortly followed up by musescore#4364), the end result was that when a newline is inserted into a text block (causing it to split into two text blocks), the second text block would always end with a newline, even if the original text block did not. This is fixed here by setting the second text block's EOL flag to that of the original text block.

This is what is attempted by the function that joins two text blocks when a newline is deleted, but that function wasn't getting it right either. So that has been corrected here as well.

Taken together, these two errors meant that there would be a blank line at the end of any text element that had ever contained a newline. This blank line would be small, but it would always be present, even if you tried to delete it.

Because this blank was always present in multiline text elements, and because it was small enough to not attract much attention, musescore#5881 only added an empty text fragment before a newline, and not after. But now that we do not have to have unwanted newline characters, in order to preserve the font size on a blank line, an empty text fragment may be needed after a newline also.
@Jojo-Schmitz
Copy link
Contributor

Jojo-Schmitz commented Feb 3, 2021

This may fix it for more than just rehearasl marks, right?

(it resolves https://musescore.org/en/node/316754, not https://musescore.org/en/node/315754)

@mattmcclinch
Copy link
Contributor Author

Yes, this fixes the issue for all text elements, not just rehearsal marks. And thanks for pointing out the typo in the link, by the way.

Of course, the thing to be aware of is that text elements in existing scores that used to have a tiny trailing blank line will now have a full-sized trailing blank line. But at least now it can be deleted, whereas up until now it could not.

@vpereverzev vpereverzev merged commit a437122 into musescore:3.x Feb 3, 2021
@igorkorsukov
Copy link
Contributor

@mattmcclinch Could you please port the changes to the master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants