Text wrapping

• Sep 18, 2011 - 01:09

I like to include explanations in my scores when something might seem ambiguous to the performer (which I'm sure isn't an uncommon desire for any composer). However, I find the text editing abilities to be missing a key feature: text wrapping! Basically, I'm inserting a frame, putting text in said frame, and... well, that's it. If the text could automatically wrap, that would be extremely helpful. It's not that difficult to manually insert line breaks, but whenever I want to go back and change the wording of something due to a change in the music, I have to spend unnecessary extra time reformatting the text's line breaks to look correct. Is there an existing workaround for this, or is something maybe in the works? Or is there a setting I'm simply missing? And yes, I know this is a small feature, but it seems like it'd be more helpful than it sounds.


Text wrap in particular, and other text handling refinements in general, are really important for a professional-level tool. Text features should if possible use orthogonal function sets that apply consistently in different usage contexts and that behave properly with respect to styles and defaults.

Though I'm not sure I would want this for normal text elements (staff/system text, etc.), for sure for text frames, because those have a fixed width.

In reply to by josiasmat

Part of the question about ordinary text elements is that there is currently no way to control their size at all, both width and height being completely variable, so first making text elements resizable and then also implementing text wrapping would probably be significantly more complicated than tackling text frames, which have a fixed width and an adjustable height.

In reply to by Isaac Weiss

For ordinary text elements, their font, size, etc., can be controlled by the text editor which appears on the bottom of the screen, and for most ordinary, unframed text elements, text-wrapping is a non-issue.

I would vote to make text wrapping the DEFAULT behaviour of text in frames, and to have the frames automatically expand vertically to accomodate the number of lines of text the user inputs.

As an example of the uses of this, I have attached a simple primer on basic harmonic analysis which I created for a student a number of years ago. (Note that I created that score with 1.3, before figured bass notation was available. I had to resave it in 2.0 and re-set the margins and staff/system spacing, but I left everything else as it was.)

In reply to by Jojo-Schmitz

Thanks; I had forgotten that. Because it's such a PITA to insert large blocks of text into a score, I rarely if ever do it (that tutorial I posted is one of the few times I've bothered). It's easier to tweak the layout so the text matter fits on separate pages from the music notation, and then assemble the whole document with a PDF editor.

If I need short musical examples in text (such as in the critical report), I LOVE the new png image capture feature in 2.0. That works beautifully with my text editing program. Unfortunately, I don't have the same image-capture capability in that program, so inserting text images into a MuseScore file requires me to take a screen-shot in WORD and then edit it using MS Paint--almost as big a pain as manually breaking the lines of text in a text frame.

In reply to by Recorder485

Also see the "MuseScore Example Manager" extension for LibreOffice / OpenOffice, which automates much of the work of generating PNG images from MuseScore into text documents, including setting up a link back to the original MSCZ file you can Ctrl+click an example in your text document and have the original score automatically loaded into MsueScore for further editing.

In reply to by Marc Sabatella

Thanks, Marc, but I don't use Open Office; we use MS Word (an older version, but it does the job so I see no reason to make Bill Gates any wealthier than he already is. ;o) One of my translators uses Open Office, and he can't read the comments I and the other editors insert using Word, so there are already incompatibility issues.

I am also not sure I would want a program loading things automatically from one file to another. When working with several programs at once (MuseScore, Word, and two different PDF editors (one for make-up and a different one for printing)) things can get out of control too easily.

In reply to by Recorder485

One of my translators uses Open Office, and he can't read the comments I and the other editors insert using Word, so there are already incompatibility issues.

Then why the heck is he still using OpenOffice instead of LibreOffice? That sounds like exactly the kind of thing that LibreOffice would have fixed long since while Apache's version of OpenOffice languished.

If you're not clear on the distinction, check out Wikipedia, or http://www.pcworld.com/article/2977112/software-productivity/why-you-sh… or www.zdnet.com/article/apache-should-deprecate-openoffice-and-send-users….

In reply to by Isaac Weiss

Heh. Actually, I was NOT clear on the distinction; I somehow had the idea that Open Office and Libre Office were simply the English and French versions of the same thing.

But for our uses, the distinction is moot. All my translators and editors except for two use one of the versions of MS Word, and I have a unlimited-installation 'educational' license for my copy of Word so those two will convert to that software shortly.

In reply to by Recorder485

It depends, if your work is centered on the text, or if it is centered on the score. It would not make sense if I have to export everything to a text editor, just because I have some paragraphs to write on the score.

Many textbooks on music, for example, have a lot of music AND a lot of text, so I think MuseScore must have at least basic paragraph handling funcionality.

In reply to by Isaac Weiss

Of course. I didn't realize that text styles apply to both framed and non-framed text. And obviously, automatic text wrapping would apply only to text frames, because it doesn't make sense to implement text wrapping for non-framed texts, since they by definition do not have fixed width. So, the best place to put the option would be in the inspector, right? And only for text frames.

In reply to by josiasmat

I am not sure I agree that text-wrapping in a frame should be an option toggled in the inspector. From my point of view, framed text should wrap by default, while staff/system text should be set flush left by default (more or less as it is presently). There is a fundamental difference between a small piece of staff text ('solo' or 'divisi' or 'take alto sax' or 'first desk only'), and an explanatory paragraph (or more) of text material which needs to be inserted into a score at some particular point.

If one of the code-writers could chime in about whether that sort of difference is possible, it might help clear up this question.

I would vote for wrapping in text frames and not in score or part instructions. But if you need possibility to switch wrapping in inspector, I will not hamper it.

There are a number of issues in text handling appart from lack of text wrapping.
1) Lack of paragraph justification
2) System or staff text will continue to expand beyond the end of system or staff and even beyond the page margin and the page edge. The expected behaviour would be to limit the expansion to the system length and then wrap.
3) There is no way to attach a foot/end note (including its numeric, roman or alphabetic cross reference) to an element such that if said element happens to jump to another page (because of relayout, for instance) the foot note go to the correct page's footer. The current behavior is that if one manually moves the text to the bottom of the page, after a page change the foot note will end according to its original offset. Foot notes are inherent to annotated scores
4) Lack of indentation option
5) Lack of tabs and their customization

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