Right aligned text does not align correctly
Ubuntu Studio 14.04, GIT commit: 8c7a103
1) new score
2) add composer text:
3) type "AAAAAAAAAAAAAAAAAAAAAAA" (just keep typing the letter "A", watching the results)
Result: the text starts of right aligned to the frame, but the more A's you type, the more the line drifts to the left
Multiple lines thus do not actually align right. The effects dependent on the specific characters. A's drift left, W's drift right, other work well. I assume line length calculations are off.
Comments
Works fine on Windows.
Yes, I don't recall having seen problems there, either. I've only been running Linux a couple of dasys now. I was wondering if maybe this was new with the recent change to width calculations. Apparently not; it's just Linux-specific (or something about my configuration - I should mention this is a self-build against Qt 5.3)
BTW, this happens for both FreeSerif and for MuseJazz.
(mistake; I meant to add a comment elsewhere)
strange, i cannot reproduce this (linux, qt5.3)
Anyone else on Linux able to reproduce? I still can with latest sources. I'll do some debugging later to see what the source of the discrepancy might be. One thing I can tell you right away - if I run MuseScore with the "-d" option so I can see the bounding box of the text, the bounding box aligns properly. There is space at the end of the text, within the bounding box.
I can reproduce under Linux Mint 13 (qt 5.3), commit f87cb01 (debug build).
See screencast:
http://www.screenr.com/bQpN
As Marc Sabatella said, with "W" the shift is to the right. And indeed, as Jojo-Schmitz said, I can't reproduce under Windows 8.1.
I wonder if Qt 5.3.1 would change anything. I'm a little afraid to update my Qt as I'm still not sure of the compatibility issues overall.
I tried with Qt 5.3.1 under Linux Mint 17, commit c24022f3 (debug build), but no differences with respect to Qt 5.3.0.
[ Side note: Due to a bug of Qt / CMake configuration of the official distribution, I had to install libegl1-mesa-dev for the compilation to succeed with Qt 5.3.1 ]
As of now, I can't reproduce this on the Linux machine I am using at the moment. It *may* have been fixed by https://github.com/musescore/MuseScore/commit/aa6b0c8e636a2f5ffeae2a549…, but I can't prove that. Unfortunately, that same change may be what is responsible for "trails" when dragging dynamics starting with the letter "f" from the palette. That glyph clearly exceeds its bbox().
Unfortunately, that same change may be what is responsible for "trails" when dragging dynamics starting with the letter "f" from the palette.
For the record, the report about that is #38221: Drag trail with dynamics starting with "f"
I also can no more reproduce the problem, Linux Mint 17, commit 12de34c (and Qt 5.3.2).
BTW, I still can't reproduce on my current machine, but I'm leaving open because I still want to investigate further when I have a moment.
One thing occured to me while working on something else - it appears in several places in the code where we need to calculate the width of a string, we actually loop through it character by character (skipping high surrogates). lasconic pointed out that this would not account for kerning. Why do we do this? For the text segments within chord symbols anyhow, I find the string width gives me a better answer than anything I have been abel to get character by charcater if the string contains Unicode double flat or double sharp characters (both multibyte sequences w/surrogates).
QT is up to 5.4.x now. Can any Linux users still reproduce this? FWIW, no issues on OS X.
I still cannot reproduce on my machine, which a build made against 5.4.1. And I haven't heard of anyone else reporting issues.
I cannot reproduce this. Can anybody?
I cannot, and assume this was indeed fixed years ago.