Inconsistent resizing of text in 1.1

• Aug 8, 2011 - 22:01

In 1.1, It seems that "most" text elements are automatically resized according to the "Scaling / Space" setting when you create the text, which is good. Volta text seems to be an exception).

If you then change the scaling parameter, some text elements are automatically resized (eg, chordnames), but others are not (eg, tuplets, staff/system text, rehearsal marks, staff names), at least not right away. After a save/reload, some of those text items *are* then resized (tuplets), but some are not (staff/system text, rehearsal marks).

I can't remember how much of this was also true in 1.0. And I know everything changes for the better in 2.0. But I wanted to see if any of this is unexpected in 1.1. If so, I can file issues.

Comments

• Aug 8, 2011 - 23:39

I touched on this subject too a few months ago.

I wonder if we should actually bother with 1.1, because 2.0 is the next version to be focused on.

I had one or two issues, but didn't file them - you may have noticed the Lilypond ones, but that's because it seems to be faulty in the trunk currently. The problems may actually be sorted, so perhaps I should have just held off, actually.

Reply

• Aug 9, 2011 - 00:10

I have no idea if another 1.X release might be under consideration or not, but I figure if it's a regression versus 1.0, it probably deserves to be logged just in case. Even if it's not a regression, it still seems like a good idea to log issues that are not already fixed in 2.0. I guess the question is, what about issues that are not regressions and that are already fixed in 2.0. My feeling is, I would like to log issue any that might actually influence the decision as to whether that 1.X release happens or not.

I know text handling was completely redone for 2.0, which is why a lot of 1.0 issues relating to text weren't fixed for 1.1. It seems some of what I've described might be a regression. Either way, if any of this has a chance of being made to work better in 1.X, that would be good to know.

So my thought is, when in doubt, post here first. If folks on the development team would rather we adopt a different strategy, that's fine by me too.

Reply

• Aug 9, 2011 - 09:45

We don't know yet if we will release another minor version on the branch. It will depend how severe the problems are.

Something very useful that need to be done for the trunk is to check the compatibility of scores created with 1.1 against the trunk. It could be as simple as :

  1. Download a score from MuseScore.com or from Made with MuseScore forum
  2. open it in MuseScore 2.0
  3. Check differences (and don't stop there!)
  4. Try to create a short score in MuseScore 1.1 to reproduce the difference in MuseScore 2.0
  5. Post the score, necessary steps, OS, MuseScore trunk revision you tested in the issue tracker with [Trunk][CPT] in the title. (CPT standing for compatibility)

Reply

Do you still have an unanswered question? Please log in first to post your question.