While looking for ways to improve / extend font support via Qt, I found this Stack Overflow post: http://stackoverflow.com/questions/24673444/which-opentype-gsub-features-does-qt-4-8-support (which, its title notwithstanding, also deals with GPOS features, like "kern", and also covers 5.3).
I have no idea how reliable this info is, but it may show a potential way to go.
1) The set of OT features supported by the custom-compiled' Qt 5.3 lacks the feature(s) I believe to be most important for our main application field (musical glyphs), i.e. the stylistic alternates (feature "salt") and the stylistic sets (features "ss01" - "ss20").
2) It also lacks features which are of great importance for a proper typographic rendition, like small caps (feature "smcp") and 'old style numerals' (features "pnum" and "onum").
3) The post also gives a reason for the different behaviour of Qt font management under OSX.
I see two possible strategies:
A) By-passing Qt font management altogether, directly accessing the underlying font stack, to free us from the recurring bugs of this Qt area, from the apparent lack of interest in it from the Qt dev team and from the special OSX case.
On the spot, I have no clear idea how possible / feasible this would be. It seems very likely it will be far from simple, both on the side of OT support itself and on the side of integrating 'our' code with Qt drawing primitives.
B) Improving Qt support by fixing bugs potentially still there and adding more OT features to the 'experimental' Harbuzz support by Qt. This also would not be simple, but the coding part could follow established practices and patterns of the existing Qt code base.
This would however require some commitment and recurring work to keep up with on-going Qt development, until 'our' improvements are not back-ported to main Qt, if this is at all likely to happen. Also, it would probably not address the special treatment of OSX.
In any case, it would be a rather medium-to-long term project. Comments and suggestions are welcome.
According to https://bugreports.qt.io/browse/QTBUG-18980 Harfbuzz-NG is the default *shaper* now in Qt 5.4.
My understanding is that the font *layouting & rendering* is still different per platform,
* Linux uses Freetype
* Mac OSX uses CoreText
* Windows uses GDI. Freetype can be activated with a command line flag https://musescore.org/en/node/38301#qt-options but then the whole UI uses Freetype and MuseScore looks even more alien on Windows
See Freetype: https://framapic.org/KiWHj8qplJxP/N9Cu43Yd and GDI: https://framapic.org/INpe0jSc1yIW/0svHbSze
Also DirectWrite can be activated when compiling Qt but it will work only on Windows Vista and up.
Another interesting read http://blog.qt.io/blog/2011/03/14/hint-hint-nudge-nudge-say-no-more/
Note that as the maintainer of the Windows and Mac OSX builds, I avoided to compile/configure/patch Qt myself so far except to contribute bug fixes. Maintaining our own Qt "fork" would be costly...
As Maurizio explained, there are two very different problems currently and I'm not sure we have identified them well.
1/ MuseScore 2.0 suffers from the difference of font rendering on different platforms.
- In particular, texts can look different (kerning, width). One bug to illustrate https://musescore.org/en/node/33481.
- Another issue: the reported metric of a font glyph is different depending on the platform. In extreme cases, MuseScore figured out that a measure doesn't fit on a line on a platform, while it will conclude that that the measure can fit on the line on another operating system. It leads to scores looking different on different OS regarding system breaks.
- Somehow the font rendering is "bolder" on some platforms. The best way to get it is to run the visual tests suite on another system than Ubuntu Precise with xvfb-run. Even running MuseScore on the same system but a "real" X server seems to give different results but as fas as I know we never did precise research on this.
I don't think we understand yet the root causes of these issues. These issues are also interacting with PDF rendering issues and font embedding.
2/ MuseScore 2.0 doesn't (and cannot) use OT features. That's a totally different problem and I would love to get a better understanding of what we could do better/more if it was possible. Looking at SMuFL, I do have some ideas... but actual use cases would be better.
2015-04-13 0:39 GMT+02:00 Maurizio M. Gavioli <[hidden email]>:
While looking for ways to improve / extend font support via Qt, I found this
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
Mscore-developer mailing list
Glad to know! This seems a step in the right direction.
Thanks for the summary of the current situation.
Of course, this is just my opinion but, having to choose between consistency across platforms and "native-look"-ness on each platform, I would prefer the former. Incidentally, the screen shot you give about using Freetype under Windows does not look particularly alien to me or strikingly different from the default; I agree I may not be a very neutral observer, though.
However, it is not clear if we do have any choice at all. The kerning issue on Mac you quote (https://musescore.org/en/node/33481) is typical: as Apple and Microsoft disagree in their vision of some OpenType details, their respective implementations are different and relying on system routines is likely to produce different results.
I suspect very few peoples do understand them; developers or teams with substantial experience in dealing with text processing across multiple platforms may have developed empirical strategies to circumvent them, though.
The current point with Qt, even with 5.4, is that it may use OT features, but does not expose them (at least I could not find any place where it does). This means that supported features are activated by default and unsupported ones are deactivated, but there seems to be no way to turn on/off individual features in specific spots. This is (possibly) convenient for features which apply unconditionally, but it is not for features the user may want to activate locally.
For instance, if a font includes the "kern" or the "liga" features (which are supported by Qt since several versions), kerning and/or ligatures will be activated by default, but there seems to be no way to turn them on/off on demand. So, it would not be possible to activate a feature like "ss01" (stylistic set 1, which is anyway currently not supported by Qt) on specific glyph runs.
Assuming a way is found (or will be provided by Qt in the future) to solve this, I would distinguish between two major areas of application:
A) Musical glyphs: for the most part, they are drawn individually, then most of the GPOS and many of the GSUB features are useless for them; using stylistic sets or stylistic alternates, however, could be a way to give the user access to (part of) the variety of shapes and styles possible within SMuFL.
B) Textual glyphs: text runs may benefit from theoretically all the features (as they have been developed specifically for text! Some apply to only some scripts, though); it would then be a matter of deciding how far to go from within MS, optimizing the flexibility and the typographic appropriateness with the usability. I personally would love to see the day when MS will allow to use 'real' small caps and lower-case numerals.
In reply to this post by Maurizio M. Gavioli
Two years have passed and things do not seem to be very different. Qt code base now does include HarfBuzz (since a few versions), but it is unclear to me if it uses it at all and if it gives an application any (more or less) direct access to it.
I could do a scan of recent forum topics / issues and get an idea of the current MS status about text shaping / laying out / rendering, but if anyone has a summary, I would appreciate.
In particular, to see if it would make any sense to add HarfBuzz to 'our' font stack below FreeType, giving MS access to some of its features, and steer away from Qt text processing completely, which in my opinion might be the most logical option in the mid term (and the road to version 3 is mid term at least).
|Free forum by Nabble||Edit this page|