Thanks, that worked 
1 Like
Do some plugins load “system” fonts rather than “plugin” fonts?
I have a lot of plugin source downloaded for Rack V1 so I can search. In those I only found system fonts loaded in the vcrack-packone-1 plugin.
I don’t have so many downloaded for V2, so I can’t easily search.
One or two I have seen the code for do.
One argument against using the “system” fonts are that if they ever change, any plugin using them will break.
2 Likes
Yeah, I think this may warrant further discussion here as to what the best practice is. Thanks.
I didn’t say anything about performance, this is primarily related to storage and deduplication of files. Having default assets to fall back to, or get started with, would be nice though.
Rack 1 has two fonts in the system /res/fonts folder. Rack 2 has nine fonts. The two in V1 are still present in V2. Hopefully this group of assets is persistent and will not go away in the future, but I suppose only @Vortico can answer this question: “Is it a best practice to load the system/res fonts if needed rather than distribute those same fonts?”
The fonts added in V2 look like they could go a long way in eliminating the need for as many fonts to be distributed with plugins. V2 fonts include DSEG7 (mini-bold, mini-italic, mini-bold-italic, mini-light, mini-light-italic, mini-regular) in addition to sans serif regular, bold and mono.
Of course, there will always be the need for custom or special fonts to be distributed with plugins along with their license terms.
System fonts won’t be removed unless no plugins on the VCV Library use the resource. If we need to remove a font from the Rack distribution, we’ll ask all plugin developers using the font to switch to a local copy and wait until all plugin updates are on the VCV Library before removing them in a Rack update.
5 Likes
I’m working to make my PurrSoftware Meander plugin/module V2.0.19 load only Rack system fonts and distribute no fonts. I already have it working for basic panel runtime text and 7 segment displays, but I need to spend a while tweaking it.
Edit: I will still distribute the Bravura music OTF font.
Just a quick update on this effort. I was able to modify my Meander module to use only Rack system text font files and thus not need to distribute any text fonts. I’m pleased with the results. Converting to the Rack system DSEG7 seven-segment display font was not just a drop-in replacement. I did have to recode the logic for my 3 seven-segment display widgets due to differences in how character widths are handled with the DSEG7 fonts versus the open source seven-segment font I currently use.
I will wait a few more days before submitting the new version to the library, since V2.0.18 of Meander only came out yesterday.
As a reminder, Meander uses nanoVG for all panel graphics and text at runtime. Also, the Bravura OTF music font will still be distributed.
3 Likes
I’m changing my approach a bit regarding fonts. I could not keep the panel appearance of Meander close to the existing appearance if I changed all runtime fonts to Rack system fonts. I could do a lot of work with font sizes and maybe get close, but, I’m not going to do that.
In the end, I switched to the Rack system fonts Nunito-Bold.ttf for two panel widgets and the DSEG7ClassicMini-Bold.ttf font for my 2 7-segment display widgets. But, I am sticking to the use of the “Ubuntu Condensed 400.ttf” for several of my panel nanoVG text draw functions.
Personally, I still think that for new modules it could be a good practice to only use Rack system fonts, but, it is difficult to re-engineer an complex existing module without have to do quite a bit of work and still not being able to exactly duplicate custom open fonts.
I will submit these limited changes to the library soon. The panel should appear ~identical to the current and historical Meander appearance.
2 Likes