g.getStringWidth is broken in 4.0.0 and g.setFont will not display Oxygen

[Lindon]

@cynthasiser

I notice in your snippet you haven't loaded the font, does it make any differnce when you

Engine.loadFontAs("{PROJECT_FOLDER}Oxygen-Regular.ttf", "Oxygen");

Engine.setGlobalFont("Oxygen");

Make sure your font is in the project Images folder

[d.healey]

@cynthasiser said in g.getStringWidth is broken in 4.0.0 and g.setFont will not display Oxygen:

Oxygen works fine when I use it in a label so it's definitely on my system. If you run this snippet, are both strings in the same font? For me the top one (set as Oxygen in the paint routine) displays as Arial, but the bottom one (set as Oxygen in the font component of a label) displays correctly:

Both are the same when I open the snippet, but the spacing is different.

Neither of those fonts looks like Oxygen to me - same in your image. The top one looks more like Oxygen but it isn't. I'm assuming we're referring to this font - https://fonts.google.com/specimen/Oxygen

[Lindon]

@d-healey perhaps because Oxygen isnt loaded?

[cynthasiser]

@d-healey

You're right, your second one looks like Arial again with no spacing, and mine doesn't seem to be Arial OR Oxygen, its got the 'g' with a loop which neither font has (looking at the Google Fonts site). Is Oxygen definitely the selected font in your label? Do you have the option for Oxygen in the drop down menu? It's right at the top for me:

When I search for Oxygen in my HISE folder I find it in HISE-4.0.0\hi_core\hi_images along with a few other fonts. The date modified is the exact time it was compiled so it must be native, but it's in a different place to the other fonts.

I think it might be an old version of the Oxygen font that HISE uses in its own display. Image below shows the words "Interface Designer" as they appear in the HISE UI, and then below, a HISE label in Oxygen, 3.5, saying the same thing, they look the same to me!

So the Oxygen font shows up in the drop down font menu in labels, but cannot be accessed by g.setFont(), I guess because it doesn't look in the folder that Oxygen lives in.

I'll download the current version of Oxygen and load it myself like @Lindon suggested to avoid any more trouble. Perhaps it's worth hiding the font from users in the drop down to avoid the confusion?

[Lindon]

@cynthasiser yep it all renders the same if you load the font correctly:

HiseSnippet 1060.3ocsV8uaaaCDlxIJH1qcXEXO.D9uTv7LrS6ZGPwPsi+Qg2RhMh851vvP.sDkLWnHUknRhSPvdEG5Cw968FjcjR1Vd0YcyX0.1v7t66zGOd2G0nXoKMIQFirJOYdDEY8H6wyEpYclQXBzftHqO09DRhhFiyLcz7HRRB0CYYsyq0FrJuKx74Oe0QDNQ3RWYBgdij4ROlExTqrNp02w379DO5DVXgneVqAtRQGIWlB7YG6FnHh6Ej.5oDcXkrQV60yiojwiUDEMAYs6QRu4imIuRjE+aXIrobpdQSzXHQYl6K4dZFqsh5Liw8FsXemffrLZUUXmrpvmaeByisz9ppwmYbfWgnX8vpz5zam0nWyhzqQA5sAJYUfR6lQomXO1MlEoV4QymOwdf.Nb7IPYuHUxhEU5OJY2QBQHT0CIWP6GCKVhv44MZTCC+bvKqzSDvDz5bIwqODS6Dmp2N5rgeauNSNu+vi616r6Fd87.p3KOiFjxIw0UJ+p0vUyrVERwhbjPUulKmR35D4TL.33MQgujDiCmOhHnb72fWPu.ppiLLRJnZPFuMMfxCUm1Qvwf5LYpBdLN9oBWESJbBNnxsUJGT2G5pZy4NYcPI0I2jFSgL.t7hIWcrFDreOTuoal+8oZ+UJqojmLXB8ZEPoppYT7aSYtWfmFCmdXe403eMMLh5gkWBiBZ+bxMy0XpZRPfldqseg7e3pGdaNKPP8zO.m7GTM7OaXCPhFl+7KP0jS8UUy3DTXRjbZ8nXlNsFtcEySMCyRvUweANPWyFq.2A+f19hDefF+GDc9g0lSAvj1wLB2rKpganS4cG7xEkbrTbpTQGJbLk9J2UA+2c46uQe5S6XImSi2nasfP7+DPGQZ3TZbMnIhmRWFHLkr9nm8CO5UTYvMq4qPfRw.ASMLhJdH8BTdGK7uuePWhhnmWysAwEQiULMEr5RuDD+xldKa2klbgRFA5XKayQV6qLde7hYaciNhASv6amMAfttnZ57hKXJZ3Bwxx68t6e28qa8vhlMG8KQ252ZMixBlUPT9mZgJvqJqyqiISy40irkl16IzD0CxstsTPODxpt8+kAIjFzpMDjGCy8gJa1E.6amMZYLMlcSgqNbZs9F72usEQOwEZ1M6YqGqfKddOQUPNW5ApYp0030Wrk6.59VSXUKdJRXp4Eu36+Mg++sT7I1iXJ2Yalik1.GgdzOFbL+5xGa2y2m5pVQvcs6+iebtaDko+GbBAjsfNP6SSCGC8LtT3oKfYF8zuUI8bZ15F505JvXpvyr3d3Styl50V4NatvIJj3FKO2MSyQeg79FK.mDlVwxvKEAqwMQFcnh04P38CN20c8T8d.ObaA9zsE3y1Vfe01B74aKvWrs.+5OLP8qu0NUICyFaPnSF0yHhaY0SPfNPS2J5u.kBZGSC

[cynthasiser]

@Lindon

Still seems like an issue that Oxygen shows up in the font drop-down menu. It makes the user think it's a native font that g.setFont() could render without trouble.

[Lindon]

@cynthasiser said in g.getStringWidth is broken in 4.0.0 and g.setFont will not display Oxygen:

@Lindon

Still seems like an issue that Oxygen shows up in the font drop-down menu. It makes the user think it's a native font that g.setFont() could render without trouble.

Well you need to be a bit more sophisticated than that., when comparing these two examples : One is loading thru the HISE application itself and the other is loading and rendering in your application,.. So essentially the difference between running your application in HISE, and running it compiled.

Frankly this font loading is one of the first things I learned in HISE and I've been doing it ever since. I'm not sure if its part of the current learning resources for newbies, if not then it should be.

[cynthasiser]

@Lindon

So is it normal practice to copy any fonts you want to use for a project from your system's Fonts folder into your HISE Projects Images folder and load them in code if you're using paint routines?

I can't remember where I learned to use g.setFont() but it always worked with all of the default Windows fonts without loading them like this so I never realised it was part of the process.

[Lindon]

@cynthasiser said in g.getStringWidth is broken in 4.0.0 and g.setFont will not display Oxygen:

@Lindon

So is it normal practice to copy any fonts you want to use for a project from your system's Fonts folder into your HISE Projects Images folder and load them in code if you're using paint routines?

Yes, even if you are not using paint routines, you have no way of assuring yourself that the user will have the specific font you are using - so you need to ship the font with your application, by placing it in the Images folder and calling Engine.loadFontAs

I can't remember where I learned to use g.setFont() but it always worked with all of the default Windows fonts without loading them like this so I never realised it was part of the process.

And your MacOS users? - They will likely not have your default Windows fonts...

[cynthasiser]

@Lindon That makes sense, thanks!

Loading fonts seems to have fixed the issue with g.getStringWidth() in 4.0.0 too.

It's weird that it worked correctly even on unloaded fonts in 3.6.2, but in 4.0.0 using it on unloaded fonts gives you an incorrect pixel width. It's like the Windows fonts were loaded by default in 3.6.2, but in 4.0.0 they're loaded wrong. Could that difference in behaviour between versions indicate some kind of problem?

And is it worth adding a warning to users (whether in the software or in the documentation) when they use g.setFont() on unloaded fonts if the intention is that fonts should always be loaded in code? To me, the font loading part in the documentation reads as an option for adding your own fonts rather than a necessary step. I think I just read the correct syntax for setting a font, tried it and it worked, so I never had an indication that anything was wrong until now.

Either way, it looks like neither method is bugged, they just misbehave when you don't load fonts properly, so problem solved!