Better typographic support? RFC

Thanks to everybody for their replies. I am glad to see I am not alone in this feeling. A few additional comments, in no specific order:

• I do not know if MuseScore is the best music notation software out (t)here, as I do not know all the others; I believe we all would agree that it is at least one of the best... ;)
• «Qt should not be an obstacle [...] It's more likely due to the font engine used». As far as I can tell, Qt is the font engine, as all text drawing operations are routed through Qt drawing functions.
• About Qt and OT features:
  Since a few releases, Qt itself embeds harfbuzz as a shaper, which would allow a very great control on OT features, but unfortunately they chose not to make it available to client applications.
  The net result is that Qt designers decided which features Qt should turn on (or off) at startup and the app cannot say anything, So, liga is turned on, probably rlig and clig are on, some of GPOS are on (including kern) which are pretty basic settings and this is all.
• For sure, Qt include also some kind of formatter, some of which is accessible and may probably be used, allowing to add some additional text layout features with relatively little effort. I still have to check Qt docs, but I expect it to provide line height and justification support. Almost certainly it provide word-wrap.
• The example of Scribus is suggestive: thanks, @enkidu! (why I didn't think of it myself?). I'll check how they manage to do their magic. Because, just to make an example, adding a directly accessible harfbuzz to MuseScore would be a non-trivial project but definitely doable (and, yes, @mike320, I am the one guilty of the tabs and Fig. bass...) but, in my Linux machine this would result in:
  • a copy of harfbuzz (and one of Pango) run by the system,
  • a copy of harbuzz (and one of their formatter) run by Qt,
  • a copy of harfbuzz (and probably another of Pango or another formatter) run by MuseScore;
    a bit excessive, isn't it?
• AFAIK, kerning is turned on automatically by Qt, if present in the font (which nowadays we can take for granted); it does not like all fonts, though, and in some it used to ignore kerning data, but things did improve lately.
• Justification is a very important addition. Thanks!

P.S.: @Marc, I agree that my example of tracking is not the best possible; in part I had to juggle with fonts to have small caps shown in MuseScore, in part, the example does not look at its best, as it is magnified quite a lot to show the details, at its own scale it looks better (size is important and affects result consistency!).

Tracking and kern are related, as both have to do with inter-character spacing, but kern is between all occurrences of specific pairs of character because of their shapes (any occurrence of the pair “AV” will be kerned by a specific, negative, amount), while tracking applies to all characters in selected passages («in that stretch of text, add/remove 100 EM between each pair of characters»).

As the OP, I'll try to summarise at this stage and add some comments. Firstly, it seems to me that, generally speaking, this topic is not felt as secondary, but as bringing perceivable improvements to the engraved scores.

What is “in” and what is “out”; without turning this post into a treatise about typography (for which I would not be qualified):
* spell checking is out, I would say, as it relates with contents rather than with presentation: typography begins (or should begin...) when you are sure of the contents and you can deal with its ‘looking’, to make it as clear, readable, etc. as possible.
* word wrap however is probably in, as it does not touch at the contents and is strongly connected with justification (both require an enclosing rectangle) which is definitely ‘typographic’ in nature. Also, ‘simulating’ word wrap inserting CR here and there is not really (not always?) viable, as this rules out the possibility of justification: the last (or only!) line of a paragraph is not justified, as a norm. So, if justification is in, word wrap is needed.
* hyphenation is probably borderline; I would prefer not to deal with it, as it is a can of worms, for which there are already tools for it (outside MS, true); it also has to do somehow with contents.

This might be a preliminary set of features to (attempt to) arrive at, very roughly in order of importance:

1. line height
2. justification & word wrap
3. OT features (yes, I know, another can of worms...)
4. tracking
5. other ‘font effects’ like strike-through (which is rarely used, though, even less in a score...) As far as I have something to say, underline is out! Underline has nothing to do with typography, it is a useless legacy of the typewriter time, totally irrelevant and even harmful in the present time of nice, rich and rather complete type faces.

Regarding @mike320 urge about a centralised approach to this, I believed it was rather clear in the OP, but I'll repeat here in full word: anything of this kind should be implemented at the lowest possible level, to make it globally available to as many textual elements as possible. Some may not have (or not always have) a use for this or that detail, but it should be there should they need it.

At first sight, the best place seems the TextBase class, but other know MS code base better than I do.

Now, something more technical. I browsed the Qt docs about this and:

• Qt QPainter (which is the class used by MuseScore for all drawing, texts included) already knows about word wrap (simply but effectively) and justification. So these could be implemented relatively cheaply (a part for UI and some internal details).
• It does not seem to know about line height, which is strange, unless I boldly missed it. This is a pity, as it forces a client app to do almost everything by itself: if it has to place each single line, it has to split the text into lines (word wrap) and justify it. If anybody has any hint, please shout!
• QFont knows about tracking (in several forms)
• As I already suspected, Qt in general offers no way to access the OT features of a font.

So, a summary at this stage may look like:

1. word wrap, justification and tracking can be implemented relatively easily (UI a part) and relying solely on Qt, if nothing else is implemented.
2. implementing anything additional (currently mostly line height and OT features) requires to bypass Qt, implementing a MuseScore-specific font stack and doing everything ‘by hand’. MuseScore-specific does not mean reinventing the wheel from scratch, libraries exists and can be used but all the logic has to be coded.

Note also that doing something in 1. and then decide to go with 2. means dumping anything and restarting from scratch. So, wise planning from start is critical, even if implementation proceeds by small steps.

Aside: I know that lyrics and Figured bass already implement the line height concepts; for both it was essential and, lacking a general support, whoever implemented lyrics (Werner, I suppose) — and myself for the F.b. — had to do a ‘local hack’...

After spending some time on Qt text processing, I may have found a possible route, using the QTextLayout class.

This class manages word wrap and justification (as well as other alignments) by itself and, while not managing directly the line height, it makes rather easy to achieve it manually. For instance, I obtained the following with a method of only ca. 15 lines:

where the line splitting and the justification on specific line widths are made by Qt itself, once a line width is set; the different line height are also obtained rather easily.
Note: this is a mini-application I made independently from MuseScore, as altering MS own text formatting would have required a big intervention and a much longer time. It replicates the kind of painting environment MS has, though, so the test should be realistic.

Two open points remain:

1. Any word-wrap and/or justification requires a line width. Line width, as well as line height, are new concepts for MuseScore and might require some non-trivial refactoring.
2. Should we in the future opt for a separate shaper (say harfbuzz) to have full access to OpenType features, QTextLayout can go only part of the way. The most promising tool might be QGlyphRun, which QPainter is able to draw directly.