Section marker and chord name share an effect band row and overprint

[maxRwalker24]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When a bar carries both a section marker and a chord name, the two texts are laid out in the
same effect band row and drawn at the same y, so they paint on top of each other, for example
"Verse 1" printed straight through "Am".

This affects any section marker that has a chord name near it, so in a typical chord-chart
score every section label is overprinted.

Related but distinct: #1560 covered the tempo marker overlapping chord symbols and was resolved
in 1.4, and the key signature was moved to its own effect band in 1.8. The section marker vs
chord name collision remains in 1.8.4.

Expected Behavior

Expected: the section name and the chord name occupy separate rows above the staff.

Steps To Reproduce

Reproduction

\title "Marker / chord overlap"
\tempo 120
.
\track "Guitar"
\section Verse "Verse 1"
(0.5 2.4 2.3).4{ch "Am"} 0.5.4 2.4.4 2.3.4 |
\section Chorus "Chorus"
(3.6 2.5 0.4).4{ch "G"} 3.6.4 2.5.4 0.4.4 |

Reproduction fiddle (alphaTab 1.8.4 from CDN): https://jsfiddle.net/maxwalker/r3ncLagd/

Expected: the section name and the chord name occupy separate rows above the staff.
Actual: both are drawn at the same y and overlap.

Link to jsFiddle, CodePen, Project

https://jsfiddle.net/maxwalker/r3ncLagd/

Version and Environment

[AlphaTab][VersionInfo] alphaTab 1.8.4
[AlphaTab][VersionInfo] commit: 022a45c8e42370f9e12e68949d11eada370da83d
[AlphaTab][VersionInfo] build date: 2026-07-05T14:46:18.224Z
[AlphaTab][VersionInfo] High DPI: 1
[AlphaTab][VersionInfo] Platform: Browser
[AlphaTab][VersionInfo] WebPack: false
[AlphaTab][VersionInfo] Vite: false
[AlphaTab][VersionInfo] Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36
[AlphaTab][VersionInfo] Window Size: 1754x1129
[AlphaTab][VersionInfo] Screen Size: 2560x1440

Platform

Web

Anything else?

Analysis

Effect bands are packed into shared rows by EffectBandSizingInfo.getOrCreateSlot, which asks
EffectBandSlot.canBeUsed(band). That decision is made on beat ranges only; the rendered text
width is never measured.

Source at the v1.8.4 tag:
https://github.com/CoderLine/alphaTab/blob/v1.8.4/packages/alphatab/src/rendering/EffectBandSlot.ts#L46-L75

public canBeUsed(band: EffectBand): boolean {
    const canShareBand =
        (!this.shared.uniqueEffectId && band.info.canShareBand) ||
        band.info.effectId === this.shared.uniqueEffectId;
    if (!canShareBand) {
        return false;
    }

    // first beat in slot
    if (!this.shared.firstBeat) {
        return true;
    }

    // beat is already added and this is an "extended" band connecting to the previous bar
    if(this.shared.lastBeat === band.firstBeat){
        return true;
    }

    // newly added band is after current beat
    if (this.shared.lastBeat!.isBefore(band.firstBeat!)) {
        return true;
    }

    // historical case, doesn't make much sense, but let's keep it for now
    if (this.shared.lastBeat!.isBefore(this.shared.firstBeat)) {
        return true;
    }

    return false;
}

Both effect infos opt into sharing:

MarkerEffectInfo.canShareBand is true, with sizingMode EffectBarGlyphSizing.SinglePreBeat
ChordsEffectInfo.canShareBand is true, with sizingMode EffectBarGlyphSizing.SingleOnBeat

So a marker and a chord name on the same beat can be placed in the same slot and receive an
identical y. Because their sizing modes differ (the marker is drawn left-aligned from the bar
start, the chord centred on the beat), they occupy overlapping x at the same y and overprint.

Because width is never considered, two wide texts on nearby beats can also collide even where
the beat-range comparison itself behaves as designed.

Workaround (and why it isn't usable for us)

Forcing canShareBand to false on the MarkerEffectInfo instance in
Environment.defaultRenderers fixes it completely. The marker claims an exclusive row, chord
names move to the row below, and the existing slot sort puts the marker on top, which is the
conventional engraving anyway. Verified in Chrome against 1.8.4: 3/3 section names overprinted
before, 0 after.

It isn't viable as a userland fix, though. Environment.defaultRenderers is @internal, and
more importantly the patch only takes effect in the realm that lays the score out. Since layout
runs in a Web Worker that imports its own copy of the module, the patch would require
core.useWorkers = false, which is not workable in our integration.

Suggested fix

Either:

give markers an exclusive band (MarkerEffectInfo.canShareBand => false), or
take the rendered text width into account when deciding whether two bands may share a row.

Thanks for alphaTab, we use it in a guitar teaching platform and it has been excellent.