Better typographic support? RFC

• Nov 4, 2019 - 10:13

So far, MuseScore typographic support for textual areas has been rather rudimentary, probably because Qt support for this is rudimentary to start with.

Someone may reply that text is secondary in a music notation software. I do not believe so: textual elements are many and diverse in scores: from longer blocks with additional stanzas at the end of vocal scores, to the myriad of smaller elements: title/composer/subtitles blocks, tempo indications, performance or stage (for operas) annotations, copyright marks, running headers and footers, ...; different functions, different requirements and, often, different typographic solutions.

The following is an initial list of features which any programme intending to support text beyond Notepad should implement (and, in fact, most of them do implement), approx. from the most to the least important.

  1. Line height is essential: currently MuseScore is fixed at 0 leading, which results in text blocs as ugly as these (additional stanzas at the end of a vocal score):
    EsempioInterlinea.png

  2. Tracking is also rather important: MuseScore is fixed at 0 tracking, which results, for instance in this:
    SampleTracking1.png
    which could better look as (reproduced outside of MuseScore):
    SampleTracking2.png

  3. Access to OpenType features. This is very important; I am a bit surprised that previous calls for it (by myself or other: search the site for "OpenType") had no consequences. It is also a pity that, when Qt at last included OpenType support via harfbuzz, they made the very dumb decision of not making it accessible to client applications, which makes things unnecessarily complex.

Relevant OpenType feature include (again approx. from more to less important):

3.1.: Upper/lower case figures (also called "lining" and "old style" figures), i.e. the lnum and onum features (the tnum feature is probably less important, once one can be sure that the pnum feature is activated).
3.2.: Small capitals, both in the smcp and in the c2sc flavour (c2pc and pcap being less important, as very few fonts implement petite capitals).
3.3.: Additional ligatures: clig, dlig, hlig, rlig, assuming liga is automatically activated by Qt (OT specification suggests that clig and rlig be active by default, but I have no idea what Qt decided to do with them).
3.4.: Character variants / Stylistic sets: cv01-99 and ss01-20. This could also apply to musical features for stylistic variants already recognised as such in SMuFL.

Questions:

A) As I am rather sick of tracking Qt deficiencies on typographic matters, I may be not aware of recent improvements about them. If anyone knows of them, I would eagerly learn!

B) Am I the only one feeling the need for these improvements?

C) Does anyone suggest other typographic improvements I did not think of?


Comments

I would even go so far that typography and the art of music engraving are siblings. If you want to use a music notation program like MuseScore for publications with professional demands, then a good typography is also part of it. In this point MuseScore is similar to a DTP program or should be similar.
Here are my answers:
A) Qt should not be an obstacle, Scribus (free opensource DTP software) uses Qt as much as I know. It's more likely due to the font engine used.
B) As you can see, no!
C) To the already mentioned I would spontaneously think of the justification (normal and forced) or less important the strikethrough text, double underline… as missing feature.

I know there are professional publishers using MuseScore because it is the best notation program out there. I know they exist because they occasionally request help in the forums. No-the-less, I agree text is a major part of a beautifully engraved score and it would be nice if editing the score were easier. I really don't think the issue is QT, it's contributors not thinking this is a high enough priority. They have other improvements they want to make, so text editing falls lower on the list of improvements. Text editing will also be no small task. Even a rudimentary text editor will be quite the project. We have seen people take large amounts of time to work on major projects (I believe you did tablature and/or figured bass) so you know the personal dedication such a project would take.

With the cries for better editing that have been continually heard throughout the last decade or so of MuseScore, one day someone will decide to step up and do this project.

In reply to by mike320

I know that there have been and still are publications that have used MuseScore. As far as pure music notation is concerned, you can also fine-tune a lot to obtain a very professional result.
I really love MuseScore, but I wouldn't be presumptuous enough to say it's the best music notation program out there.
If it's really about engraving, LilyPond, which I also use, is certainly still a very excellent program (also typographically). However, it has a steep learning curve, is less intuitive, and becomes very complex at higher demands. So it's not for everyone.
With the commercial programs there are also some functions which MuseScore cannot (yet) offer. It does not have to offer them either. I've been using MuseScore for a really long time now and promote it because I'm generally convinced of open source software (like GIMP, Inksacpe, LibreOffice, Scribus, Audacity...). When people criticize MuseScore, it's only because they want to improve something.
A few additional text functions, especially kerning and line spacing, would definitely be an important feature to be able to make manual adjustments to text, where typographical things go astray. Just as you can do with notes. Of course this is not easy to program and it is also a question of priorities.

In reply to by enkidu

_ it is the best notation program out there_

This is a very subjective opinion. If it weren't the best a professional would pay the relatively small price (from a business perspective) to subscribe to one of the paid programs or use one of the other free ones.

I definitely agree we can do better with text, although I suspect for most people, it's basics like word-wrap in text blocks that would be the biggest bang for the buck.

Regarding the finer points of typography you bring up, control over line spacing seems a no-brainer and I don't think Qt imposes any limitations on this - we do most line management ourselves already I believe. Tracking is a term I've heard of and have a vague sense of what it refers to but don't really understand how it plays with kerning, and in your images the MuseScore version frankly looks better to me. For the record, MuseScore does support kerning, but unfortunately some of the fonts we ship do not have good kerning info. I am hoping to take care of that for MuseJazz at least. I realize not one you're likely to be concerned with this one directly, but the info used to exist and was inadvertently lost during 3.0 development.

OpenType is supported in general, although maybe not "all" features. But I rely on ligature, substitution, and positioning pretty heavily in Campania and everything seems to work, except for vertical positioning on macOS. Not sure about stylistic sets, but given that SMuFL uses these, it would be nice indeed to take advantage if possible.

In reply to by Marc Sabatella

Let me ask you a stupid question: I'm not a programmer and therefore quite clueless. But, if another open source project like Scribus, which also uses Qt (but an older version, Qt 5.9.7), has already implemented certain functions (kerning, tracking, line height and much more), can't you take the code for it? That would be an advantage of open source software, wouldn't it? That you don't have to reinvent the wheel all the time. Creating synergies should definitely save time. But as a non-developer I might think too naive.

@Marc Sabatella: even with the MuseScore standard font FreeSerif there are sometimes kerning problems under Windows (I haven't checked macOS yet). For example, f is too far away from e :
Anmerkung 2019-11-06 105022.png

If you could fix these kerning issues manually, as you can do with notes, it wouldn't be bad. Because there will always be fonts that have kerning problems in general or under a certain OS.

A bit off topic: with Scribus you can also use fonts that don't work in MuseScore 3.x anymore, like the infamous Nyala (which came with Windows 7). That's another problem, I know, and it's probably due to the font engine used in MuseScore 3.x.

In reply to by enkidu

That f probably not from FreeSerif though, but the dynaminc taken from the Musical Text Font selected for the Score.

Edit 1: Hmm, maybe not, maybe because we're not having a FreeSerif Italic but generate those italics on the fly?
Edit 2: No, not even that, we do have FreeSerifItalic and FreeSerifBoldItalic (we don't for FreeSans though)

In reply to by Jojo-Schmitz

You mean the forte 𝆑 because the text appears in a tempo marking? I just tried it again with a system text (Ctrl+T), it's the same there:

feierlich.gif

The way it looks, it's also an italic typeface, you can see that quite well when switching between normal and italic in the GIF.

In reply to by Jojo-Schmitz

Something strange is definitely going on. I have checked standard FreeSerif bold italic (the one coming with my Linux distro) in LibreOffice and InkScape and there is no extra space between f and e.

As far as MS is concerned, both the FreeSerifBoldItalic.sfd source and the compiled FreeSerifBoldItalic.ttf in FontForge behave exactly as the standard distribution fonts (no extras space). Note that between f and e kerning is 0 in all these fonts; so, it cannot be a missing or misinterpreted kern datum.

It seems like something in MS either replaces the f glyph with something else or screws font rendering up. It happens with both italic and bold italic in all the textual contexts I tried in MS and apparently only with the f. Possibly creating an issue is in order.

In reply to by Miwarre

Maybe I'm missing something, but that looks like 0 space. That is, there is no extra space I can see, the e stars right after the f. If you want it tucked underneath, the font needs negative kerning there. Maybe I'm missing something obvious, but if there is really no kerning for the "fe" pair, MuseScore seems to be doing what it should.

In reply to by Marc Sabatella

I checked the FreeSerif fonts on my system (not sure if they are the exact same versions that MS uses) using a word processor. In all four weights, the 'e' got moved under the 'f' when kerning was turned on and moved away when it was turned off. So kerning does seem to be in the fonts. Also remember that there are two types of kerning in fonts: the older pair-based tables and the newer OpenType kerning feature. MS doesn't yet support OT features, and some fonts no longer provide the older type of kerning tables.

In reply to by redux02

The fonts used by MuseScore depend on the OS and possibly how MuseScore itself is installed (eg, on Linux, AppImage versus a particular installation from a repository). So it's tough to be general. But again, MuseScore does support OpenType features in general, including all the positioning I threw at it for Campania (except on macOS, where vertical positioning does not work, apparently because harfbuzz doesn't support it there). So I still say, if the font actually used by MuseScore has good kern info for "fe", it will kern in MuseScore.

Could be there is some sort of auto-kerning going on for italics in some programs?

In reply to by Marc Sabatella

That's for sure. The standard fonts usually don't cause any problems. But there are always badly made fonts, which you might have to use anyway, because there is no alternative. In such cases it would be very useful to have tools in MuseScore to correct such errors. By the way, this is often the case if you use e.g. Unicode characters that come from a different font than the rest of the text. There, the letter-spacing is often bad.

In reply to by enkidu

I'll reply to the first part: recycling code. The (very) short answer is: «No, not really».

The longer answer is long! First, it is not even sure that another programme is written in the same programming language as MuseScore (actually, Scribus is, but it is just luck). Second, someone would have to become familiar with Scribus code structure, which means looking at some thousands (yes, thousand) of files, trying to guess which does what and how.

Once the relevant code is identified (after several days, if not weeks), it is not simply a matter of copying and pasting it. The code doing a certain function in a programme expect its “eco-system” ( global variables, graphic context, etc, etc) to be set up in a specific way; copied into a different eco-system will produce garbage if we are lucky, but the more probable outcome is that it will simply crash (you cannot move an Alpine flower to the desert — or vice versa — and expect it to do anything reasonable or even survive). So, the eco-system has to be replicated in the receiving programme. Which leads to more investigations and creation of ad hoc code, which will be a nightmare to adjust, extend, in general maintain.

IT uses to obviate (at least partially) this problem with use of libraries, i.e. collections of code portions, designed to be reusable in different contexts with as little requirements (the “eco-system”) as possible, which are also documented explicitly. The most common library to access fonts for OT features and substitutions in general (a shaper) is harfbuzz which is included in Qt but, alas, buried internally and not accessible.

In reply to by Marc Sabatella

Hey Marc, +1 from me for the OpenType features—real small caps when supported by the font (not just resized regular caps), numeral figure styles, and tracking adjustment (considered necessary for small caps).
Also, while not an OpenType feature, accessing font weights on Mac is missed.

These typographic features would give a serious boost to the potential beauty of scores made with MuseScore in my opinion.

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»).

In reply to by Miwarre

+1 to better text control. Given that it seems complicated to go “all in”, is it possible to take a baby steps approach? As Marc suggests maybe start with word wrapping in text frames, and maybe a search function for lyrics? Not looking for a full-function word processor, just a little more than we have now?

In reply to by marty strasinger

I don't think a full-function word processor is necessary for MuseScore to be greatly improved in capabilities, but there needs to be an integrated approach when improved text editing is implemented. Most of the capabilities in one text object should be possible in other text objects. Much as fractions were implemented throughout the program, text editing capabilities need to be included in all text objects where it makes sense. For example, I don't see word wrap being useful in chords or figured bass but it would be useful in all staff and system text as well as all frames.

In reply to by mike320

It's a very different story for staff text, though, since it doesn't have a fixed width as a frame does. I guess you mean, when the text reaches the right margin of the page? That's a much more complex problem because we don't even know which text elements are potentially extending into the margin.

In reply to by Marc Sabatella

I didn't think about staff and system text having an expandable box. There would definitely need thought put into how to decide when to wrap the text. The code for actually wrapping the text should be reused.

It seems there are at least a few cases where reusing code would make sense in the existing code, but this hasn't happened so far.

In reply to by marty strasinger

I should point out that really, things like word wrap are a bit different from the sort of "typographical" things that this thread was about, so I'm sorry to have refocused derailed the discussion a bit by mentioning that. Word wrap is more about usability - saving the trouble of managing line breaks yourself - but typography is more about the actual appearance of the text.

In reply to by Jojo-Schmitz

To me the distinction is, anything you can do yourself already just by hitting Enter to add line breaks or Delete/Backspace to remove them is not typography. In other words, word wrap saves you time and effort, obviously, but there is no way to tell just by looking at a piece of printed music whether the editor used word wrap or not. Typography is about the things you can see just by looking at the printed page, not things having to do with the editing process.

But justification fits the bill - it potentially works by inserting "micro" spaces and isn't the same as simply adding extra spaces yourself.

In reply to by Marc Sabatella

My point is that no matter how you classify specific aspects of text editing, the project needs to be one project, not one PR for fixing staff text another fixing frames one PR for word wrap, one for centering text and so forth. Word wrap, justification, print styles, search and so forth are all related to word processing features that are missing from MuseScore. I'm not advocating spell check or automatic hyphenation unless there is an existing library that could be incorporated into MuseScore. I would be surprised to find one that covers enough languages to justify including it and it would probably be missing musical terms any way.

In reply to by mike320

There is already an easy enough hack for spell-checking lyrics: use the copy lyrics to clipboard feature, paste into a word processor, and spell-check activates automatically.
If you need to spell-check in another language, I’ve never tried it, but if your word processor has multilingual functions, there should be a way to enable that.
In any event, this particular feature I would not want made native to MS.

In reply to by frfancha

I think the term is “code bloat”. Spell-check is something easily handled, and likely handled better, by other programs. Let those programs worry about maintaining a multilingual dictionary so that MS can focus on its core competencies. The developers already have their hands full adding additional core features and debugging existing ones.

In reply to by Miwarre

For what concerns line height, lyrics and figured bass already have a global style property changing the line spacing, see
https://github.com/musescore/MuseScore/blob/d1411bbbb8294af2e9008a3aa0d…
https://github.com/musescore/MuseScore/blob/d1411bbbb8294af2e9008a3aa0d…
and menu item Format->Style->Lyrics (or Figured Bass)
Maybe something similar can be done for general texts, with a possible local style override (managed via the Inspector).

In reply to by ABL

I also would greatly appreciate improvements to text handling of the sort you've been discussing. I typeset high-quality books as well as music, and going from a program where I can control basically everything in my layout to MuseScore is, well, a bit of a jolt. (No, I don't think MuseScore can or should do everything that professional typesetting program can, but there is much that can be done, as mentioned above). Thanks for considering this issue; I know it won't be a small job.

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’...

In reply to by Miwarre

Looking to the long-term future, I think that line height and OT features are important. (Some of the latter are widely used and understood, such as the common f ligatures, while others appeal only to type geeks.) Even if only a few OT features were implemented to begin with, having a foundation for later additions is important IMO -- so I would suggest doing things in a MuseScore specific way rather than option #1.

In reply to by redux02

I also think they are important. With OT features, it is roughly an “all or nothing” matter: in order to be able to turn on/off even only one of them, you need some access to the underlying font stack, and at that point you have access to all of them (unless some quirk gets in between somewhere along the chain, which is always possible...). Then, building the UI for using them may come in steps.

Still replicating a font stack inside MS is not a trivial decision!

I know that type faces nuances are not perceived by many, as well as music engraving nuances, for that matter, and many scores around show this in a, hmmm... let’s say ‘noticeable’?... way. Still, when you accustom the eye to the lower case figures, you can no longer ignore how ugly upper case figures are in inappropriate contexts, just to make only one example.

In reply to by Miwarre

Building the UI was what I had in mind when I talked about giving access to some OT features. I'm not a programmer so I didn't realize the all or nothing nature of turning OT access, although it makes sense that it would work this way.

In reply to by marty strasinger

This point is important. Right now everything is still too vague to have any solid idea. What I can expect is that new defaults will be chosen to be right (or acceptable) in the majority of cases but that some corner case may show some strange behave. Very generic, I know. I am sure that the community would keep an eye on this and point compatibility issues out well before delivery.

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:

TestTextLayout.png

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.

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