Dorico Bug report

[riccardo.burato]

Annoying bug on Dorico version 6.1.10.6078 (Oct 8 2025)

MacOS 26.2 (25C56)
MacBook Pro 14”, 2021, Apple M1 Pro

See this video: Watch Registrazione schermo 2026-02-08 alle 12.38.09 | Streamable for details.

[riccardo.burato]

Basically, when moving a line element vertically, clicking the “Print” tab overrides the manual changing to a certain default position (decided how?) and prevents exporting with the wanted corrections.

[riccardo.burato]

Investigating further: there is a hidden offset between the visualized positioning of the object and the real position in the file itself, managed by the software. Switching between tabs resets the object to the real position, that is not coincident with the visualized one after moving the object.

I solved the issue by overcompensating the moving of the object “imagining” how much this offset is and overplacing the line object.

[Zalde]

Did you deactivate Avoid collisions for the line (Properties Panel in Engrave mode)? If not, that can help (the line has to be anchored to a grid position and not notes). The issue is known to the developers:

D.S. and D.S. al Coda moving around on their own between engrave and print mode

The problem here is caused by the combination of graphical position offsets applied to the repeat ending lines, chord symbols, and repeat markers in bars 37-39. It definitely indicates a bug, I suspect caused by a mismatch between the range of music that is reprocessed when you switch into Print mode (which reprocesses the whole layout) and when you switch back to Write mode (which will more often reprocess only a smaller range). There is some instability in this calculation which will require f…

The above topic was about D.S. markings but there is a link in there to a different topic about lines.

[dspreadbury]

If you have a project you can attach that reproduces this problem, please do so. If you’re able to cut the project down to just one or two pages before you attach it, that would be very helpful for us.