Right aligned text does not align correctly

• May 31, 2014 - 17:13
Type
Functional
Severity
S4 - Minor
Status
needs info
Project

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

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.

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 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 ]

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).