[trunk r. 3617] Strange issue with texts
Hi,
most of my scores, last saved with 0.9.6.2 or 0.9.6.3, exhibit a strange issue when loaded under trunk rev. 3617. Some, usually the most simple, do not, so I am wondering where the difference is.
Issue description: several texts are not recognized in the correct style and / or are not correctly formatted / positioned. This happens both under Windows and under Ubuntu.
My setup: MuseScore r. 3617
Windows XP w/ SP3, Qt SDK 2010.04 (Qt Creator 2.0.0, Qt lib 4.7.0)
Ubuntu 10.04, Qt SDK 2010.02 (Qt lib 4.6.2)
A sample score is attached: under r.3617, it shows the title moved to the right, the composer moved waaaaay to the right (in practice into the next page), the tempo indication is not recognized as tempo text style (opening the text properties, the style is not selected) and positioned too low.
An image comparing 0.9.6.3 and r.3617 is attached.
Not shown in the image: the copyright text is altogether missing.
Not appearing in this sample score, but in other (too long and complex to attach), staff text is not recognized as staff text and wrongly positioned (usually too low).
In some cases, as for tempo and staff texts, opening the text properties dlg box of each text and selecting the proper style usually sets the text at the right position; as I have dozens of scores with hundreds of texts, this is not a practical alternative, though; it also does not work in several cases. Any suggestion is welcome.
Thanks,
M.
| Attachment | Size |
|---|---|
| TextPos_r3617.png | 29.99 KB |
| TextPos_r3617.mscz | 19.18 KB |
Comments
To follow developments on this issue see
#7546: [trunk] Vertical/horizontal position of texts in frames
Thanks for the reply.
I posted that issue; this one is possibly connected but different: the issue you refer to was about texts which were always misplaced; this one is about texts which are misplaced for some scores and not for others.
I have not been able to discover any reason for this difference of results and I hope someone could cast some light.
M.
Sorry, I missed the part where you said some scores did not have a problem. I've noticed text moving around every few days in the nightlies. Today's nightly build is closest to the correct position that it has been for a while.
It seems the point is a different algorithm for formatting between 0.9.6.x and trunk. I'll try to explain (I'll stick to horizontal formatting for simplicity):
Default formatting for, say, Title can be described in words as: centered in the frame.
In 0.9.6.x, this is achieved by:
1) moving reference point to frame centre (relX = 50%)
2) centering the text on this reference point (alignment: centre)
In trunk this achieved by:
1) centering text in frame (alignment: centre)
2) keeping reference point at origin (relX = 0%)
(This difference can be seen by creating a score with default styles under both versions and looking at the resulting values in "Style | Edit text styles | Title" in each version: they ARE different)
If text styles are not customized, each version uses its own default and all is OK. But, if Title text style has been customized with 0.9.6.x (for instance changing font family or size, nothing to do with alignments), the score is saved with a Title text style saying (in some conventional way) both 'relX=50%' and 'alignment: centre'.
When this text style definition is read by trunk, the text is
1) first centered in the frame ('alignment: centre')
2) then the text is moved 50% to the right ('relX=50%')
ending up misplaced.
While each solution is totally legitimate in itself, isn't changing from one to another at version change like fishing for troubles?
Shall I file a bug?
Thanks,
M.
In reply to I think I got it by Miwarre
The old text implementation has several problems the new implementation tries to solve.
One change is the distinction between styled and unstyled text elements. Styled elements now change as expected when the style is changed. Setting them to unstyled gives the freedom to explicitly create special elements which will not loose their formatting if style changes.
Another change is the handling of text inside frames as you noticed. There was a conflict in the old implementation between alignment done inside a text element and alignment of the text element itself in the MuseScore layout routine. I think the new implementation is simpler to understand and to handle as there is no reference point anymore (its the fixed upper left corner of the frame).
The new implementation may have bugs and still is in testing.
In reply to Text alignment by [DELETED] 3
Hi Werner, Thank you for your reply.
The new distinction between styled and unstyled texts is a great improvement. I understand the new implementation is not finished and there might be rough corners (this is what testing is for, isn't it?).
My concern is about backward compatibility: the plan is to arrive at a correct interpretation / rendition of 0.9.6.x situations (at least for the commonest / simpler cases, like centered and right alignment) or a break has to be expected?
If suggestions about priority are relevant, correct interpretation of old definitions seems to me more important for styles than for individual texts, as the former may affect a large number of texts.
About reference points: trunk dlg box for text styles still contains ref. pt. data (X, Y, relX, relY); are they to go away?
Thanks again!
M.
In reply to Hi Werner, Thank you for your by Miwarre
I think most things will be backward compatible.
The reference point concept will stay for all text in a staff or system. It seems natural to achor text to some score element. I am not sure the relX relY values are needed anymore.
For frames things are different and i want handle text more like in a normal word processor. Framed text should be restricted to be always inside the frame. There is also no need to move text around in a frame. Formatting should take place in terms of alignment, indentation and frame borders. The used qt text engine also allows for tables, dottet lists, pictures etc. in text which is not yet explored but could be easy implemented if needed.
In reply to Compatibility by [DELETED] 3
Glad to hear about compatibility!
About relX, relY: in fact I do not remember having never used them (a part for text in frames, which are going to be different).
About texts in frames, as you say, there is no need to move texts in frame, usually. But I found an odd case.
Assume there is a score with multiple pieces. Only the first piece gets the long instrument list (I usually set all short instrument names to empty, in this case). This is fine in most case, as collections of pieces tend to have the same instrumentation.
Occasionally, however, instruments change (as I use MS mostly to edit early music, I can't help with this: if the original instruments change, I cannot modify this!). The only way I found, is to insert an Horiz. frame with a frame text for each instrument name and position each text using Y offset values (in spaces) linked to the staff distance. Using a single frame text for all the instrument names, it is very difficult to vertically align each name with its staff.
If X and Y offsets will no longer be used for frame texts, is there another way to obtain the same result?
Thanks,
M.
In reply to Glad to hear about by Miwarre
You can use Staff Text to label the staves. Just drag the text to the position you need it.
In reply to You can use Staff Text to by David Bolton
David, thanks for the reply.
Of course, this was my first thought. But the position of the staff label becomes dependent upon the position of the note/rest the staff text is attached to (in this case, usually the first); any small change in format moves the texts out of place.
In addition, the labels get carried to extracted parts and need to be manually deleted there.
Lastly, by using staff texts for many different things, you forfeit the usability of the "Select all" option which is VERY useful to ensure consistency.
So, I'm afraid using staff texts for this creates more problems than it solves...
Thanks anyway, though!
M.
In reply to Yes and no... by Miwarre
You can create staves for all the instruments you need and then hide empty staves when you are finished.
If the instruments change because you are starting a new piece or movement, you can create the new piece in a separate file.