MuseScore needs a font redeaux
With the issues with fonts and kerning that developed in MuseScore, especially after 2.03 in which most Windows fonts are completely unusable, I took a look at the Fonts.
It has something to do with newer QuickTime dependencies that can't be downgraded to what we had in 2.02 and the developers can't do anything about it and it's hard for them to test because most of them don't have a Windows OS on anything they own.
I'm guessing this may be because a very low percentage (maybe 10 or 15%?, I'm guessing) of MuseScore users are actually using an obscure platform like Windows.
With Musescore now it looks like the developers are fond of FreeSerif and FreeSans.
But they look terrible when put to a printer test. (See Attached)
And worse yet, if a Windows user has FreeSans or FreeSerif installed in their OS outside MuseScore, screen and print output are completely unusable.
Testable, and Repeatable, if you have Windows DON'T install FreeSans or FreeSerif into your OS.
So I started looking at alternatives.
I tested dozens of fonts in different formats. Many more than in the attached files.
The best printer output came from some old (late '90s) Adobe Postscript Type 1 fonts I had lying around.
These are not distributable so that doesn't really help MuseScore much, though that's what I think I will be using from here on.
Though if you have a Xerox 4595 printer and need drivers for your Windows 9x/NT4/Vista/XP box from helpjet.net that might help you somewhat.
But the screen fonts for those Type1 Postscript fonts look terrible.
Like in the old days when it looked terrible on the screen and great on the printer.
I found the same issue with GNU GhostScript 6.0 Fonts ftp://ftp.gnu.org/gnu/ghostscript/gnu-gs-fonts-std-6.0.tar.gz
Great printer output, lousy screen fonts.
I tried every decent "Open Source" or GNU font set I could find on SourceForge or GitHub. (See Attached.) That's where developers hang out now.
Even Adobe's Source Sans Pro and Source Serif Pro are horrid on a printer.
Though Source Han Sans https://github.com/adobe-fonts/source-han-sans/tree/release/OTF looks pretty good to me for Asian Languages, but I can't be a judge.
Then I remembered: TeX. And LaTeX. I even contributed to one of those projects a couple decades ago.
I don't remember exactly what, I think it was Cyrillic glyphs for a font used for math or something, maybe scripting?
All TeX fonts are under the GUST Font License, which basically says: "You can do whatever you want with the font as long as you change the name."
Some LaTeX fonts are under a different license, but most follow the TeX license.
Perfect for MuseScore. We (as MuseScorians) can move away from the exclusivity of FreeSerif and FreeSans.
If we need more glyphs in these fonts, the dude that wrote MuseJazz can add them and change the names.
I tried a few, all from the Tex Gyre family http://www.ctan.org/tex-archive/fonts/tex-gyre/ and most (not all) of them work great in OTF with MuseScore (See Attached.)
I mean, the bad ones are as good as FreeSerif and FreeSans, and the good ones are much better. (See Attached.)
The entire LaTeX font catalogue is viewable and available here:
http://www.tug.dk/FontCatalogue/
This would be a GREAT addition to 3.x.
That is to have some decent fonts to pick from.
And the license is right.
The music in attached file is just something I transcribed out of an old Sunday School hymnal.
It just happened to have some pairs of characters in the lyrics that MuseScore (Or QuickTime, or whatever) has a lot of problems with, especially in small font sizes.
| Attachment | Size |
|---|---|
| FontTrials.pdf | 326.78 KB |
| TexGyre.pdf | 314.82 KB |
Comments
Two things puzzle me about this.....
First - why would you regard Windows as an obscure OS?? According to Wikipedia, Windows is the most installed OS on desktop computers worldwide.....
https://en.wikipedia.org/wiki/Usage_share_of_operating_systems
Also, it was the most popular OS for MuseScore users last time I saw any statistics, which was around a year ago.
Second - what on earth does Quicktime have to do with it? Quicktime is an Apple product similar to Adobe Flash, and not native to the Windows platform - I don't even have it installed on my Windows 10 machine so I can't understand how it would affect font rendering.
As I understand it, all font handling is done through Qt, and it is bugs in Qt which are affecting font kerning.
In reply to Two things puzzle me about by ChurchOrganist
I guess Quicktime (QT) is a mistakake and Qt was meant
In reply to Two things puzzle me about by ChurchOrganist
1) Windows - snark.... Developers pretty much use Linux exclusively.
2) QT is the development platform for MuseScore. I thought it was QuickTime.
In reply to 1) Windows - snark.... by SeasonPsalt
Developers pretty much use Linux exclusively This is pretty much untrue. For MuseScore Werner uses Linux, Lasconic uses Windows and Mac
QT != Qt
In reply to Developers pretty much use by Jojo-Schmitz
OK, I've been out of that world since a little after Delphi came out. Most developing I did was in Pascal and Fortran.
There are some striking differences in your examples. I have a few questions, and I'll start with kerning and character compensation.
First, did you manually adjust the kerning of any of the common pairs (Yo / Te / Aw, etc.)? And if so, where/how did you do that? I just glanced over your examples quickly, but even so I noticed radical differences in the kerning of Yo among them.
Second, same questions for character compensation: Did you adjust the cc to set characters tighter/looser, and if so, where/how? A number of your examples show the type set quite a bit tighter than one would normally set text of that size; others are set looser than they 'should' be and some show regular inconsistencies (by which I mean a constant bad spacing of certain character pairs).
In reply to There are some striking by Recorder485
I didn't adjust any kerning. Fonts are as downloaded. All templates are identical except for one and all I adjusted was staff distance. Something happened between 2.02 and 2.03 that killed kerning in MuseScore. I'm downgraded to 2.02 because of the issue.
I reported the bug.
It seems printer output on PS1 fonts, especially Adobe, fixes the MuseScore kerning issue somewhat, not so much on TTF/OTF.
The developers are saying: "Why not just use FreeSans and FreeSerif?"
But I'm suggesting they take some of these GUST licensed fonts, and if kerning adjustment is needed they can do that themselves, and then we get a variety to work with.
The samples should be printed to really see what they look like, fonts are embedded.
In reply to There are some striking by Recorder485
See this thread:
https://musescore.org/en/node/116721
Are you a typographer? They really need help with this stuff and I only dabbled.
In reply to See this by SeasonPsalt
I am a retired typgrapher and graphic designer who has come back to the business after 40 years; now I do music publishing using the mature version of the "PC" technology that put so many of us out of business in the 1970s with promises of pie in the sky by and by. Photo-typesetting computers in the 1970s were the size of pickup trucks and looked like a desk married a typewriter and they had a television set for an offspring. They were hardware programmed, recorded data on 8" floppies, had temporary 'bubble' memory of 8000 characters at a time, and the fonts were on negative filmstrips or discs which one had to change manually. We still did paste-ups, too; only the big $200,000-$400,000 Mergenthaler systems were dabbling their toes into digital page make-up at that time.
I am not a developer; can't write code; and still run XP in a virtual machine in this Win7 computer. :) The only things I could add to this discussion would be comments on the UI or suggestions as to which parameters the user should be given access. Or artistic judgements, since typography is, after all, an art. ;o)
In reply to I am a retired typgrapher and by Recorder485
I remember those! but I never used them. When I was playing with typesetting it was on a 680x0 Macintosh with Illustrator, Streamline and Fontographer, I think I used Aldus Pagemaker.
So I guess that was what put you guys out of business.
I never used 8" floppies, but I have programmed on punch cards :-)
But, I mean, this typeface problem a real issue.
Now MuseScore beats the snot out of LilyPond for ease of use and WYSIWYG, but there's not as much control over the text output.
LilyPond uses GhostScript, if I remember right. It's actually a lot like TeX for input.
In reply to I remember those! but I never by SeasonPsalt
What put many medium and small typography shops out of business was smiling, glib hardware salesmen who promised immediately what would not be deliverable for another 20+ years--that is to say, good quality typography from digital machinery. To the owner or office manager of a medium-sized business which generated thousands of pages of miscellaneous printed matter each year, the prospect of not paying me $40 per hour to produce his office forms, or $x.xx per column inch to typeset the company's house organ was too appealing to pass up. The truly crappy quality of the output of those early wordprocessors and PCs--plus the fact that a secretary-typist is not a typographer--was happily overlooked by managers who preferred managing costs to managing quality.
Some of what you are complaining of today--bad character spacing and fit; lack of control; etc.--was typical back then, but it was ignored, as I say, because it was cheaper. It is ironic that while today's equipment is capable of producing quality equal to anything a good phototypesetter could produce in 1979, the software programs required to drive the hardware are so complex that they sometimes wind up stepping on each others' toes.
If this were something that could be addressed through coding in ASCII and Hex, I might (with hypnotherapy and copius amounts of good whiskey) be able to remember enough to help. In an attempt to keep up with the digital revolution, we purchased and installed a 'translator' unit which could accept the output of a client's wordprocessor by fax telephone, convert it to something our typesetters could read, and store that on 8" floppies. The data came in as ASCII; to add typographical formatting to the WP file, I had to program the translator in machine language on a 16-button keypad in Hexadecimal, so it would recognise codes we sent the client in advance, which used the combination "space+semicolon" as a trigger. Like this: ;B would turn whatever followed it into a B-head, which might be defined as 12/13x21.5 Univers bold, cc:02, Flush left.
But somehow, I don't think that ancient skill set (even if I could find the 40-year-old documentation) would be of much help today. ;o)
Just a note that I believe a major factor in choosing the FreeFonts for inclusion with MuseScore is the number of languages and symbols supported—see the right-hand sidebar at https://www.gnu.org/software/freefont/index.html.
In reply to Just a note that I believe a by Isaac Weiss
You are correct, FreeSans and FreeSerif do support a lot more languages (see attached). Sample is from the 2012 version.
I'm not suggesting FreeSans and FreeSerif go away completely, just that we have more options when choosing typefaces on Windows, since a lot of fonts that worked before won't work now.
In reply to You are correct, FreeSans and by SeasonPsalt
Because the kerning on FreeSerif is appalling on Windows.
Times Roman is worse, however.
I finally found that Calibri LIght is OK but I prefer a serif font for my text.
In reply to Because the kerning on by ChurchOrganist
@ChurchOrganist
Print the attached and see how you like it.
I did have to change font size to 10 point from 11.
It is TexGyreSchola in Postscript Type 1.
Font is embedded in the PDF.
Screen font doesn't look great, but prints awesome!
It is available here, and is under a TeX (Free) license.
http://www.ctan.org/tex-archive/fonts/tex-gyre/
It's easiest to download the entire package and find what you want, they're named goofy.
For Type 1 TexGyreSchola install the four qcs*.pfm files from the Type1 folder, (right click, install) (Win7, correct?)
There is also an OpenType version in the same location which may look better on the screen but may not print as well. You can try it, though.
Just so you know, TexGyreHerosCondensedBoldItalic won't install on Windows (Postscript Name over 29 characters) in case you install the whole lot, but that's the only oddball.
I can email you a MuseScore Style and the modified MuseScore score if you like the output and want them.
In reply to @ChurchOrganist Print the by SeasonPsalt
I should have mentioned: You can have EITHER the .otf font OR the Postscript Type 1 font. NOT BOTH.
And when you install the a Postscript Type 1 font on Windows, you should have the *.pfb file that has the same name as the *.pfm in the same directory, or else Windows will make its own pfb file that won't work as well.
BTW, if you wish to install FreeType or FreeSerif, they should still kern OK, *if* you make sure you install a version with compatible kerning information. There are quite a few mutually exclusive different ways kerning information can be encoded. Methods that work for one program on one OS won't work for another program or another OS. It's a very complex topic and quite unfortunate.
Anyhow, changing fonts doesn't solve the problem - making sure the kerning information is encoded for that font in the method required by the software for the particular OS is the trick. And unfortunately, this seems to change with each new version of the libraries, so it is hard to track. If you'd like to help test future versions of MuseScore, be sure to check out the nightly builds.
In reply to BTW, if you wish to install by Marc Sabatella
Marc, this might be one of those 'stupid questions', so feel free to laugh at me, but could kerning be controlled on a pair-by-pair basis via a dialogue or Inspector parameter within MuseScore itself? Kerning specific pairs of characters involves moving one of the two closer to (or, rarely, further from) the other. MuseScore already has 'offset' ability for many (if not most) elements; could this be enabled for individual characters in a text field?
When dealing with text-sizes (as opposed to headline sizes), it's usually enough to apply a general set of rules for the most common pairs that need kerning...but when we get into headline sizes (14-point and above), the individual shape and characteristics of each letter in each different typeface and font make it almost essential for the typographer to adjust the kerning by eye, manually.
In reply to Marc, this might be one of by Recorder485
Kerning *is* defined on a pair-by-pair basis - it's defined within the font itself. The problem is, the *way* that information is stored can be in any of several different formats. Some formats are recognized by some programs / libraires / OS's, other formats are recognized by others, but there is no single universal format that guarantees all programs / libraries / OS's can read e to make it, and unfortunately, the formats are mutually exclusive. At least that's my best representation of how it works. Bottom line is, it is hard to get one single font file to work equally well on all systems. Sometimes you need different versions of the font for different systems, where the font information is exactly the same, but the kerning information is stored differently within the font. It's a royal pain, actually. We went to some trouble to make the fonts we ship kern on all systems - sometimes by making different versions of the fonts - for 2.0, but it's possible something fell through the cracks between 2.0.2 and 2.0.3 in that department.
Which is to say, the font Arial (and the other fonts that show problem on certain systems with certain version of libraires and certain applications) *does* contain pair-by-pair kerning information. It's just in a format that only certain OS / library / application combinations can deal with. Creating a custom version of Arial with the kerning information saved in a different format - which should be possible using any font editor - would like fix the problem for that particular OS / library / application, but then break it for another.
It's unfortunately impossible to control how proprietarty third party fonts encode their kerning information. So if they choose to use a format that doesn't work with some specific OS / library / application, you're just out of luck. And that appears to be the case with the specific proprietary third party font Arial on the specific OS Windows and the specific library FreeType and the specific application MseScore.
In reply to Kerning *is* defined on a by Marc Sabatella
Okay, thanks; that's a very clear explanation of the problem and I can see why it's such a difficult thing to solve at that level. Lack of standardisation among third-party suppliers is always an engineer's nightmare....
What I'm wondering, though, is whether MuseScore could provide users with the ability to manually adjust the position of a single letter or pi character, the way it does for noteheads, stems, flags, dots, ornaments, lines, brackets, etc., as well as for defined unit blocks of text material. Not a global override of the kerning code, you understand, but something completely independent of that code. Let the font place the letters where it wants to, but give the user the ability to select and move one character afterwards.
Hmm. I'm thinking about this a bit more, and moving a single character could present additional issues as to whether the characters following it would move along with it or not. Actually, the way manual kerning was done in the old mainframe typesetting computers was to place the cursor between the letters and then insert negative spacing units (each equivalent to 1/72 of a point). There was a dedicated key for that on one of the control keypads; an experienced operator would type the first letter of a combination, hit that key the appropriate number of times, and then continue typing the rest of the word, barely slowing down in the process.
Is that sort of thing possible?
In reply to Okay, thanks; that's a very by Recorder485
Well, it's already possible in MuseScore, just define two separate text elements and position them manually. In theory, this could indeed be automated - internally MuseScore could break up your text into separate chunks and give you fine control over the positioning. But this is getting pretty far out of scope for a notation program.
In reply to Well, it's already possible by Marc Sabatella
Yes, I can move a text element anywhere I want to. But unfortunately, the program doesn't allow the individual characters within a text element to be moved independently of the rest of the characters in it. IOW, if I have a subtitle or text which says, Voluntary and the kerning code in the font doesn't like the way my OS talks to it, I will need to tuck the 'o' back under the overhang of that capital 'V'...
...but I can't. I can select the 'o' and I can even use the wysiwyg text editor to make that one letter bold, italic, or whatever independently of the rest of the word...but if I attempt to move it left by a few hundredths of a staff space using the horizontal offset in the Inspector, the entire text moves left, not just the letter 'o'. (Unless that's changed since 2.0.1?)
As for this kind of control of text being out of scope for a notation program, I disagree. There is virtually no music published which contains no text matter whatsoever, so any music notation program needs the be able to integrate text matter with the musical notation. That said, I would not think it reasonable to ask MuseScore to comprise functions such as multi-column text formatting, bulleted/numbered lists, Drop caps, and so forth. Texts which require that sort of formatting are better created in a program designed for it, with any required music content on the page being pasted in as a PNG image copied from MuseScore. But the fit and placement of letters and characters within a word or line of type is the sort of basic control that is needed to produce a professional-looking product. It is equivalent to the ability to adjust the position of a single note in a passage because its default placement is mathematically determined by its actual width, and that cannot take account of the optical illusions that can occur due to other nearby elements.
Notice the D4 at the end of each of the two measures. In the first measure, it looks too close to the A3 before it because of that ledger line. But the note is in fact the same distance from that A3 as the A3 is from the F3 before it, as you can see if you look only at the stems. But you wouldn't look only at the stems; you look at the notehead, and it looks wrong even though it's mathematically right.
So, a manual adjustment is needed here, something that has to be done by an experienced eye(see the second measure). [ETA: Ooops; you'll have to click on the image to see the whole width, sorry.] It's a small adjustment, but it makes the difference between an 'okay' rendering and a professional one.
We need an equivalent level of control for the text material in MuseScore.
In reply to Yes, I can move a text by Recorder485
I agree MuseScore should produce nice looking text. But it is up to font designers to produce good kerning info. If they do their job properly, MuseScore wouldn't need fancy overrides. Of course, we do need to make every effort to honor the kerning info that *is* present; that's the real issue her.
Anyhow, you *can* do what you with that text - it's just that, as I said, you will need to separate that text into two separate elements to get independent control.
In reply to I agree MuseScore should by Marc Sabatella
If I have to create two separate text elements for each badly kerned pair, that's what I look at as a non-starter of a solution. Even as a workaround it's barely thinkable, with all the fiddling around required to anchor two texts to the same note or rest, move them apart so they are not one on top of the other, then move them by eye until they are fairly close together and resemble a single word, and finally fine-tune the space between them to a hundredth of a staff space. I would do that only in the most dire of cases, such as a main title that really looked bad, and I would chew my teeth and mutter many, many unprintable words while I was doing it. We need something better.
Could you not create a 'negative space' unit and add it to the special characters palette that comes up when we click on the weird icon at the left of the wysiwyg text editor? If I could insert x-number of incremental negative spaces between two letters when in text-edit mode, that would do the trick.
In reply to If I have to create two by Recorder485
Well, it's a problem only if you use a poorly-kerned font, or if MuseScore is not properly honoring the kerning information that is there. the former is not something I feel a notation program should be dealing with - if the font is defective, choose another one. The latter *is* a problem we should fix. So again, assuming we are correctly honoring the kerning that is present in the font, I just don't see why a notation program needs to be providing further control above and beyond what the font designers themselves intended.
Maybe you can find a font that already incldues such a "negative space" character, placed there by a font designer who was hedging his bets?
In reply to Well, it's a problem only if by Marc Sabatella
Given the erratic nature of software engineering--too many brilliant people doing their own thing; no practical way to ensure standardisation--it is probably inevitable that typefonts will continue to be produced with a variety of kerning algorithms written to different code standards. If you can write code that can read them all, then all we as users will have to deal with is the artistic judgement of the programmers who wrote the kerning rules. But that's not something to be lightly dismissed. I know in advance that there is ZERO chance I will agree with every assumption made or decision taken by those people, brilliant in their field though they may be. I can't write code, so I don't expect those who can to agree with my artistic judgement. I spent 20+ years learning graphics; most of you guys have spent that long or longer learning to write good computer code. Fair is fair, after all....
Providing users with a manual tool which can override or replace the embedded kerning info on a case-by-case basis--whether that code is being properly honoured by MuseScore or not--seems a logical way to approach this. Sure, it would be great if you could figure out how to read the differing codes from different font producers, and even better if all those codes were absolutely perfect for all applications...but until that time arrives (dream on, my friend!), please give us control of the details. We might not always make the best decisions, either...but at least we'll be the authors of our own posterity.
In reply to Given the erratic nature of by Recorder485
MuseScore 2.03 is overriding OpenType and TrueType kerning tables in Windows.
MuseScore 2.02 didn't seem to have the issue, or at least as badly.
Postscript fonts seem to work OK in 2.03, or at least their kerning tables.
You can see this by merely changing font size of the font. Following is an OpenType (OTF) font.
Notice the glyph pairs with issues change from size to size, the same font.
In reply to MuseScore 2.03 is overriding by SeasonPsalt
That's pretty much the bug report you filed at #117191: [Windows] Font kerning issue with lyrics in 2.0.3 not present in 2.0.2, right?
In reply to MuseScore 2.03 is overriding by Isaac Weiss
yup.
In reply to MuseScore 2.03 is overriding by SeasonPsalt
FWIW, I can't reproduce this on Linux with any font I have available. If you have a particvular font file you can share that you feel best demonstrates the problem, please post it to help us test.
In reply to FWIW, I can't reproduce this by Marc Sabatella
I don't think you will be able to reproduce it on Linux.
I'm fairly confident it's a Windows (I'm using 7) issue, either with newer Qt! or Windows itself, or the way newer Qt! interacts with Windows.
It happens with almost all TTFs, and with some OTFs.
In reply to I don't think you will be by SeasonPsalt
Moving this part of conversation back to https://musescore.org/en/node/117191
In reply to Yes, I can move a text by Recorder485
Notice the D4 ... In the first measure, it looks too close to the A3 before it because of that ledger line. But the note is in fact the same distance from that A3 as the A3 is from the F3 before it, as you can see if you look only at the stems... and it looks wrong even though it's mathematically right.
I don't know if it's my browser (Internet Explorer) but I see the stems as not mathematically the same distance. However, as you show further along in your example, the spacing can be adjusted, unlike the kerning issues which you have expounded upon with such erudition (and tenacity) both here and elsewhere in the forums. I have learned a lot from reading them, so thanks for that.
Also, your 'Voluntary' example (above) I found interesting, as large font sizes (which seem to amplify any kerning shortfalls) are often used on score title pages. Forum contributor SeasonPsalt has a humorous post regarding something similar:
https://musescore.org/en/node/116721#comment-528561
Regards.
In reply to Notice the D4 ... In the by Jm6stringer
Hmm, you are right, my dear sir. I am embarrassed to note that while talking about optical illusions, my own supposedly well-trained eye got fooled by one. On my screen, the difference is not quite as big as you measured, but there is a diff. I must need (new) glasses. Again. Darn it....
And yes, I had seen that photo-gag. Obviously posted on the internet by some old typographer muttering imprecations into his beard about how kids these days can't do anything right. ;o)