Justify text feature

I vote for this feature.
However there are some details to take into account.
1) Text should never be allowed to go farther than page margin. Or, if this could be disabled as an option, never should go past the page edges. Whenever this happens, wrapping should proceed and, if enabled, the paragraph should be justified.
2) Two new types of text should be introduced: a) A fixed size box (with editable size of course, but once selected it would keep its size until it is resized); b) A foot note box asociated with rest, note or chord
3) A floating text box not linked to any score element but atached to specified coordinates on the page would be also interesting, particularly for preliminary notes, biographies, and so on.
4) Tabs should also be interesting.

This indeed comes up often in the forums too

I would say that everyone recognizes it would be nice to have some day, so eventually it probably will rise high enough in priority. But, to be truly useful for text, there are many more features that would also be needed, so it's hard to decide how to approach this.

"The perfect is the enemy of the good" (Voltaire).
I think it is a question of setting a few priorities and starting. It is not a question of having a full-rank text processor at the first attempt. Some priorities would be, IMO:

1) Allow two types of text boxes: a) auto resizeable up to the margin as text is fed into, and b) user-customizable fixed width (using the mouse or numeric properties).
2) Word wrapping. In the case of 1a) it wraps when reaching the margin. In the case of 1b), it wraps when reaching the custom width of the box. In both cases, vertical space is increased to make room for the new line(s) and the staves are pushed down.
3) Paragraph justification with the four standard options (left, right, center and full justification).
4) Allow three types of box attachment: a) usual attachment to note, b) floating, with position relative to page or page margins, regardless of the content (useful for title and comment pages), c) foot note (useful for text notes to prevent excessve clutter on the music itself). In this case, the foot note is attached to a note and goes at the bottom of the page where the note happens to fall after any relayout. Autonumbering would be useful.

I think that if these features are provided, many of the advanced features one expects from a text processor would be, at first, attainable as workarounds. Without them, any workaround is not reliable and the final relative position may be chaotic after any relayout. Besides, it is excesively prone to corruption due to MS future version changes which could eventually change layout.

I like these ideas a lot.

In general, I understand and sympathize with the idea that one shouldn't let the desire for perfection get in the way of making improvements at all. But, I think there are legitimate reasons not to rush into an implementation that may turn out to be incompatible with a future design that solves the problem a better way.

So to me, it is best to discuss these ideas in the forum and get more people involved. There have of course been previous discussions on the topic, so best to find and link to them, and also read up on them and borrow any good suggestions / consensus from there.

How about a single command on the text toolbar that justifies (or, rather, fills) the text in a box to its current size? You can use it or not use it. It does nothing unless or after invoked.

That's probably easy and safe enough. Although - are we really talking about justification, or about word wrap? I can't really see the former being that useful without the latter. And regarding justification 0- doing this by adding spaces between words is probably not idea, I think good algorithms also adjust spacing within words. We'd have to settle to for the extra spaces.

Also, of course, only frames have sizes, and that size is "all the way to the right margin". Right now right margin on a text frame seems ignored, but hopefully it could be honored here.

So, this does all strike me as a hack, but a useful one to be sure. It does make me wonder about the possibility of implementing as a plugin.

I meant "word-wrap at space boundaries", not "true justification"; I said "fills"; I meant word-wrap at spaces, hard returns maintained.

Justify and word wrap are different issues

I'm probably not the only one who uses the term "justify" sloppily to mean both or either. I wouldn't want padding justification.

I can't find an issue for word wrap, but there should really be one, and seperate from this justify issue here.

.

Thanks for #301121: Text-frame word wrap ;-)

(In reply to Marc's post Feb 13, 2020 - 11:44)
Just to be informed, what would be the specific source of incompatibilities with a future solution?
I have been following different free software and refactoring seems to be common. May be in the long run it is somewhat inefficient but in the meantime, valuable new features are added to the application.

Until the future solution is in place, it's hard to say what inconsistencies there might be. But for instance, maybe it's decided to make the word wrap a property of the text style rather than the frame? Or maybe we introduce a new "paragraph style" abstraction and put the wrap functionality there. Other possibilities I'm sure. And that's the point - until you know where the walls are going to go, you might not even realize you've painted yourself into a corner.

Generally, in word processors, word wrap isn't a text or frame property but a default behavior (I haven't yet discovered how to disable it, either in MS Word and Libre Office). Where it happens is a property of the paragraph (the text up to the next line feed), and is a series of distances relative to the frame limits (generally to the left and right, but they could be also from top and bottom) . You could simulate disabled word wrap by setting a negative distance from the right limit (if that feature is available), which could even be outside the page border, but once the value is reached, word wrap takes place.
Now, justification is a paragraph property. This is the case in most word processors.
Probably it is not necessary to reinvent word processors, but just to look at successful examples out there such as Libre Office, from which it would be even possible to borrow some code.

Well sure, because text is the main thing in a word processor, not an element you add separately. Whereas a word processor has no concept of music and wouldn’t be able to wrap measures automatically like MuseScore does.

But anyhow, that again is my point - until we design exactly how we’d like it to work long term, it’s dangerous to try a quick and dirty hack.

Text is a much more standard kind of data than music, and its handling is well stabilized since decades ago.
And text procesors, besides plain text between margins of a page (a special kind of frame), deal also with exactly the same kind of object we are talking about: a frame containing text that can float over other elements. The only difference is that those frames or boxes can be attached to certain elements, such as notes or rests, and induce autoplacement of other elements, thing that MuseScore already does, so controlling what happens inside a box as regards word wrap and paragraph properties (including features such as justification, tab position, etc.), is the only additional behavior required. This is what could be inherited from other FOSS applications.

Indeed. Which is why, again, I'm saying that until this happens - until we figure out how to best incorporate standard text features into the design of musescore - it would be a mistake to do a partial implementation that might turn out to be incompatible with the eventual design.

Is this still a live and unresolved issue? I wrote something today and had to faff about to get the text to look halfway decent, which would have been more or less trivial in a word processor. Surely we shouldn't wait forever for "perfection", though I understand that MS4 will have significant improvements, but hopefully this kind of feature will be addressed when that is released.

Like BSG I'd settle for an automatic line wrap as a first approximation - that would at least take about half of the effort out. Perhaps being able to copy and paste directly from a word processed document formatted to exactly the right size and maintaining the layout and features might also be a way forward.

yes, still live and unresolved indeed