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

Refactor the way ledger lines on half and whole rests work #25454

Open
2 tasks done
rpatters1 opened this issue Nov 6, 2024 · 1 comment
Open
2 tasks done

Refactor the way ledger lines on half and whole rests work #25454

rpatters1 opened this issue Nov 6, 2024 · 1 comment
Assignees
Labels
engraving feature request Used to suggest improvements or new capabilities P3 Priority: Low

Comments

@rpatters1
Copy link
Contributor

rpatters1 commented Nov 6, 2024

Your idea

Instead of using the ledger-line alternative SMuFL symbols for half, whole, and (potentially) breve rests, attach line extensions to the non-ledger-line alternatives.

Problem to be solved

The current approach of using the ledger line alternative symbols introduces a number of undesirable artifacts.

  1. The design of non-ledger-line and ledger line symbols can vary quite a bit within a given font. Sometimes the two symbols are significantly different. A particularly noticeable example is the difference between breve-with and breve-without in the Leland font. (Breve-with is much narrower.) There are also slightly noticeable differences in MuseJazz between the half rests. The with-ledger lines half rest in Petaluma is a completely different size and looks like a cue rest.
  2. Some SMuFL fonts do not contain glyphs for the ledger-line versions. An example in MuseScore is Finale Broadway, which substitutes the glyph from Bravura.
  3. The thickness of the ledger lines does not match either the thickness of ledger lines in the Style settings or the thickness of staff lines.
  4. In some fonts, the ledger-line symbols do not correctly vertically align with non-ledger line symbols. Here is an example with Finale Maestro:
Screen Shot 2024-11-06 at 4 52 05 PM

Given that MuseScore has an initiative to welcome Finale users, it seems like this defect in Finale Maestro support could be more than a triviality. However, MuseJazz also exhibits this problem.

Prior art

Finale uses only the non-ledger-line symbols. It then attaches line extensions to them that are the same width as staff lines and the same length as ledger line extensions. (Actually Finale has separate L/R ledger line extension values for rests, but I am not suggesting MuseScore should necessarily adopt this.) Finale's approach has a number of advantages.

  1. No special logic is required. Finale always attaches the line-extensions regardless of the vertical position of the rest.
  2. At no point do the line extensions appear when they are aligned on staff lines, since the line thickness is the same. (This is important especially for breve rests, if we ever implement Breve rests outside the staff should have ledger lines. #25230.)
  3. The line extensions appear when the rest is aligned on a space, even in the middle of a staff. Personally I prefer this behavior, but others might not.

Additional context

No response

Checklist

  • This request follows the guidelines for reporting issues
  • I have verified that this feature request has not been logged before, by searching the issue tracker for similar requests
@muse-bot muse-bot added the feature request Used to suggest improvements or new capabilities label Nov 6, 2024
@bkunda bkunda added the P3 Priority: Low label Nov 8, 2024
@irwir
Copy link

irwir commented Nov 10, 2024

  1. No special logic is required. Finale always attaches the line-extensions regardless of the vertical position of the rest.

Simple special logic will save on substantially more expensive drawing of ledger lines over staff lines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engraving feature request Used to suggest improvements or new capabilities P3 Priority: Low
Projects
Status: To do
Development

No branches or pull requests

6 participants