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.
lasconic
2015-04-13 0:39 GMT+02:00 Maurizio M. Gavioli <miwa...@miwarre.org>:
> 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.
>
> Notes:
>
> 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.
>
> Thanks,
>
> Maurizio
>
>
>
> --
> View this message in context:
> http://dev-list.musescore.org/Qt-and-OpenType-tp7579162.html
> Sent from the MuseScore Developer mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> 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
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Mscore-developer mailing list
> Mscore-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mscore-developer
>
------------------------------------------------------------------------------
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
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
