[Interest] Font issues.

[Rutledge Shawn]

On 29 Dec 2013, at 12:25 AM, Joshua Kolden wrote:

> I'm having difficulty with QtQuick font support. I can't quite be sure where the issue is, but it appears that Qt does not support ttf fonts with styles / SubFamilies, or it may be an issue with font weights.
> 
> In particular if you go to any old font on Google fonts and download it.  Say "Raleway" you'll get many 'subfamilies' of the font "ExtraBold" "ExtraLight" "Thin" etc.  However, QML will only render Bold and Normal.  Even if I only give it access to a single file like "Raleway-Thin.ttf”
> 
> This post suggests that this might be by design if it's a font family naming issue: http://stackoverflow.com/questions/17521578/qml-font-style-naming-issue-mac-linux-platform-differences
> 
> However these font files draw properly in every other application I’ve tried.
> 
> Ttf fonts from google fonts and other sources, and in general css font specifications define font weights in the hundreds with 400 being 'normal' however QML uses internal constants Font.Light, Font.Bold etc, that are in a range of 0-99 and doesn't seem to allow any numbers other than the small set of defined constants.  So it may not be name, but  that I can't define the weight properly "Railway Thin" is defined at weight 100.
> 
> Ttf fonts from google fonts and other sources, and in general css font specifications define font weights in the hundreds with 400 being 'normal' however QML uses internal constants Font.Light, Font.Bold etc, that are in a range of 0-99 and doesn't seem to allow any numbers other than the small set of defined constants.  So it may not be name, but that I can't define the weight properly "Railway Thin" is defined at weight 100.

http://www.w3schools.com/cssref/pr_font_weight.asp

so the only valid values are 100, 200, 300, … 900, and they don't all have names?  Or is it a continuous range from 0 - 1000?

FontConfig uses the following numeric values

/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_THIN		    0
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_EXTRALIGHT	    40
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_LIGHT		    50
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_BOOK		    75
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_REGULAR	    80
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_MEDIUM	    100
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_DEMIBOLD	    180
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_BOLD		    200
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_EXTRABOLD	    205
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_BLACK		    210
/usr/include/fontconfig/fontconfig.h:#define FC_WEIGHT_EXTRABLACK	    215

(plus a few more names that are duplicates), but I think the full numeric range 0 - 255 will probably work; it seems that's what they were aiming for.  Maybe a floating-point range 0 - 1.0 would also make some sense, but you can't have floating-point enums in C++.

So CSS has 9 possible values, FontConfig has 11, and QML has only 5:

	• Font.Light
	• Font.Normal - the default
	• Font.DemiBold
	• Font.Bold
	• Font.Black

A number would be more flexible.  It's also nice to have the enum values, but then we should probably have more than 5, unless there is a problem to support them everywhere.  If we had 9 values like CSS, they would need to map to suitable weights on every OS.  And I agree it's a bug if we cannot switch to different TTF files that have the same family name, but I think that depends on our use of FontConfig on Linux, and other mechanisms on other OS's.