Curly braces in Leland wrongly scaled when staves are hidden

• Jun 20, 2021 - 18:03

Piano scores normally use systems with two staves, but in some cases, a system with three staves might be needed for just a few bars. This can be achieved by adding an extra staff (in Edit→Instruments…) to the (complete) piano score, by vertically extending the brace and bar line of the second staff to the third one, and by hiding the empty staves within systems (in Style→Score, including the first system).

The problem is that this approach causes an improper brace scaling even in the two-staves systems where the third staff is hidden (for Leland, Bravura, MuseJazz, Petaluma).

Here is for comparison a normal piano score (two staves per system overall):


and a piano score with one three-staves system:


I measered the brace width difference in these examples to be 0.36 sp (by reducing the Bracket distance in Style→System until the first bar line was on the left page margin).

The problem seems to be related to Issue #313601: Curly braces in Leland, Bravura, MuseJazz and Petaluma don't scale properly when extended to more staves, which was solved by selecting the brace symbol (small, normal, large, larger) depending on the overall score number of staves per system (for 1, 2, 3, ≥ 4, respectively).

I see two possible solutions for this problem:

Solution A:

Select the brace width per system according to the number of staves really shown. So here a normal brace would be used when the third staff is hidden and a large brace when not.

Using different brace widths (large in the second system of the example above, normal in the first and third system) might cause improper alignment of the first bar lines of each system (here at the beginning of bars 17 and 34). Solving this by aligning the x positions of the brace ends to be equal would cause different x positions of the brace begins and might be hard work in the layout computation.

By the way, the Henle edition of Estampes by Claude Debussy does use larger brace widths for three-staves systems (only), but with its first bar line properly aligned to two-staves systems above and below. They also have that first bar line on the page margin so that the brace overlaps the margin, causing the systems' first bar lines to match vertically the systems' last bar lines on the page overleaf, as you can see if you hold a sheet against the light.

Solution B:

Use the current logic to select a brace width according to the overall score number of staves per system as a default, but add a property in the inspector where the width could be changed (values small, normal, large, larger) for the overall score. This would cause the same brace width to be used for the complete score, but the overall width could be changed by the user.

1. All braces in the source have the same width according to the user's choice.
2. The rendering of existing scores is not changed (until the user selects a different brace width).
3. A layout with matching first/last bar lines on overleaf pages (when holding a sheet against the light) is still possible (by setting Bracket distance in Style→System to a negative value or by using asymmetric page margins).

Would it be possible to solve this scaling problem using the approach B?

The score files for above images are Piano-2.mscz and Piano-3.mscz .


Attachment Size
Piano-2.png 22.77 KB
Piano-3.png 38.35 KB


It is different glyphs being used there braceSmall, braceMedium and braceLarge or some such, depending on how many staves are spanned. Also a fix wold be even easier, by just counting visible staves at the Pont where the decision is made which glyph to use.

In reply to by Jojo-Schmitz

I am not sure whether I understand this correctly. Would this include two changes:
 • counting visible staves as opposed to counting (score-global) instrument staves and
​ • doing so dynamically where the brace is being used (for each system separately)?

Can this be done in a way so that the bar lines at the beginning of each system would still align vertically, independently on the existence/number of hidden staves? (Then it would be similar to what I tried to describe as solution A.)

If the vertical alignment cannot be achieved, maybe solution B might produce an optically better result:
 • stick to the current implementation of counting (score-global) instrument staves,
 • but give the user the possibility to override the choice globally by a property.

Do you still have an unanswered question? Please log in first to post your question.