-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a custom and uniform font #214
Comments
Just a question (haven't studied sources) but how does the text rendering work at the moment? VSTGUI stuff uses its own path and stuff on screen other one? |
I'd say that for on-screen stuff the font would best to be fixed-width because that leaves a lot of choices for optimizations (i.e. render them as bitmaps and scale instead of wasting cpu on rendering vectors). For menus and such you can use vectors because they are not constantly updated. I.e. load a fixed-width vector font and pre-calculate bitmaps of it on several sizes. Lato might be good for menus and high-level UI components but it is not a good choice for on-screen stuff just because it is not a fixed-width font. You loose a lot of optimization angles by using it. You really want to optimize the constantly updating on-screen stuff to the extreme. This is especially important if we ever want scale Surge down to iOS or Android. |
Lato is perfect, its very pretty and and renders digits at constant size so its very well suited to numerical diplays. @jsakkine |
yeah I think there's really no cpu benefit from a fixed width font nowadays and the UI is all double buffered properly anyway. @kurasu yup the vstgui uses the installed platform font tools in the PlatformFont class underneath CFont it seems. I took a quick tour after I opened this issue. Right now the 3 fonts we use in surge seem to be Lucida Grande (mac), MS Sans Serif and Arial (windows); and the "system small font" about screen. But this issue is really about "how do we include a ttf file with our bundle which is loadable". |
OK, cool. Where is the text/number rendering code located for on-screen display? |
It’s all in the vstgui lib. Look in src for setFont and you will find the draw command. Pull from there The font object will load any ttf file which is in your path. How do you include it in the bundle and put it in the path? |
Thanks. Will look into this at some point. |
Cool. Happy to hop on slack sometime to tell you what I’ve learned about vstgui so far if that’s of interest |
This is not a pretty diff. But it is in the middle of some code which is very explicit about layout and the layout was wrong. As shown in issue surge-synthesizer#295, the combination of graphics, box placement, and label on the lfo selector were just a bit off. This makes it almost not a bit off. Ideally surge-synthesizer#214 will save the day in the future by letting us have a uniform font across all platforms.
Well just a bit of experimenting tells me ATSAPplicationFont doesn't work for .component bundles. |
Just dropping this here for my next attempt |
https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-addfontmemresourceex for my windows attempt too |
https://developer.apple.com/documentation/coretext/1499468-ctfontmanagerregisterfontsforurl?language=objc sorry to spam this issue with my notes but I keep getting 5 minute windows to look and don't want to forget |
Sigh OK so this is easy to make work on mac but harder on windows. Let me put my notes here VSTGUI uses direct2d api for drawing. That means the platform font is a direct2d font created with the direct2dfactor->CreateTExtFormat method. This happens in vstgui/lib/platform/win32/direct2d/d2dfont.cpp Now unfortunately vstgui sets the font factory to "NULL" which means use the system factory, and there's no way through the vstgui API to tell it otherwise. So I'm down in direct2d code trying to figure it out rather than the easy AddResourceFontEx thing above. May clean up and PR mac on its own just to get us rolling. Still debating. |
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system
OK decided to move us forward with MacOS only. I think Linux may actually be the more important next choice to be honest, since the fonts there are more haphazardly chosen and some users had crashes. Will peek at that code for a few minutes but then I'm mostly offline for the weekend. |
So with Windows and Linux it won't be quite as easy, mostly because the VSTGUI API is a bit in our way. Basically we need to be able to reset the PlatformFont on a CFont object. The PlatformFont for linux just has a cairo_font thingy inside which is easy to create from a binary but we have to thread it through. So we have a couple of options 1: We can modify vstgui a bunch to allow us to weave stuff through. I don't recommend this Basically where CFontDesc::getPlatformFont does if(platformFont==null) platformFont=IPlatformFont::create we want to have set the platformFont before then. on linux we want to set it to a subclass of platform/linux/cairofont.cpp's Cairo::Font which has the binary load on windows we want to set it to a subclass of platform/win32/direct2d/d2dfont.cpp's D2DFont which basically has the nasty CreateTExtFormat hack you can google And then force the subclass back up in probably using the CFontDesc copy constructor Something like that lets us add our API without having to gut vstgui Not easy. But not impossible. But not tonight. |
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system Even though the mac code to accomplish this is small, the windows and linux code will be bigger, so introduce a new C++ file "RuntimeFont.h" which defines Surge::GUI::initializeRuntimeFontFromDistribution and implement that in src/mac/RuntimeFontMac.cpp
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system Even though the mac code to accomplish this is small, the windows and linux code will be bigger, so introduce a new C++ file "RuntimeFont.h" which defines Surge::GUI::initializeRuntimeFontFromDistribution and implement that in src/mac/RuntimeFontMac.cpp
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. To do this cross platforms, introduce a new C++ file "RuntimeFont.h" which defines Surge::GUI::initializeRuntimeFontFromDistribution and implement that in src/mac/RuntimeFontMac.cpp, Windows, etc. This PR implements for Mac and Win and neither implements nor references the symbol in Linux. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system This change implements that in Windows by doing the following 1: Including the font in the .rc file and subsequent res bundle as a binary 2: Load the font and place it in a well known temp file 3: Load that temp file into the font registry using AddFontResource 4: Following the subsequent standard cfont implementation.
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. To do this cross platforms, introduce a new C++ file "RuntimeFont.h" which defines Surge::GUI::initializeRuntimeFontFromDistribution and implement that in src/mac/RuntimeFontMac.cpp, Windows, etc. This PR implements for Mac and Win and neither implements nor references the symbol in Linux. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system This change implements that in Windows by doing the following 1: Including the font in the .rc file and subsequent res bundle as a binary 2: Load the font and place it in a well known temp file 3: Load that temp file into the font registry using AddFontResource 4: Following the subsequent standard cfont implementation.
This is not a pretty diff. But it is in the middle of some code which is very explicit about layout and the layout was wrong. As shown in issue surge-synthesizer#295, the combination of graphics, box placement, and label on the lfo selector were just a bit off. This makes it almost not a bit off. Ideally surge-synthesizer#214 will save the day in the future by letting us have a uniform font across all platforms. Former-commit-id: ed9a0761d9c23c63fbf5f1f7ad9459cc117b0dfb [formerly 3918de4] Former-commit-id: f65788df6e07b0bafcb45574f4d5ebca92989c77 Former-commit-id: 0a5f39519166dbf681d94330e28218c0d823461f
As described in surge-synthesizer#214, we want to use the OFL-licensed font Lato for all components in Surge with the constraint that we want to ship the font with the DLL and not require it to be installed on an end users system. To do this cross platforms, introduce a new C++ file "RuntimeFont.h" which defines Surge::GUI::initializeRuntimeFontFromDistribution and implement that in src/mac/RuntimeFontMac.cpp, Windows, etc. This PR implements for Mac and Win and neither implements nor references the symbol in Linux. This change implements that in macOS by doing the following 1: Introducing the font to resources/fonts 2: Moving the fonts to the bundle with scripts/macOS/package* 3: Moving the font initiation for minifont and patchfont to runtime rather than surge dll load time (but only do this for fonts which USE_RUNTIME_LOADED_FONTS, which right now is only MAC. Once all platforms are done, that switch will disappear) 4: Write the MacOS specific CoreText code to load a font from memory into the system This change implements that in Windows by doing the following 1: Including the font in the .rc file and subsequent res bundle as a binary 2: Load the font and place it in a well known temp file 3: Load that temp file into the font registry using AddFontResource 4: Following the subsequent standard cfont implementation. Closes surge-synthesizer#214 Former-commit-id: 4e13f3971cc7030d0a2c87e5a8a83ceacfe8a463 [formerly dde17b5] Former-commit-id: ec2872a4ad6a52979691dc4774f5833fd3d9e63e Former-commit-id: 357261ae57bff1c95e12518c8ef058c4037f2c95
The design folks would love to use the open font @cyanit @itsmedavep
https://fonts.google.com/specimen/Lato
To use it reliably in draws we would want to include it in the resources so we can load it in app without requiring it installed on the underlying system. That’s platform dependent.
It also may or may be something we get done. But lets put an issue in place since it would make painted labels more consistent with vector graphics and stuff if we use a scalable vector thingy.
On windows and linux I haven’t googled yet. On Mac I found this:
ATSApplicationFontsPath (String - macOS) identifies the location of a font file or directory of fonts in the bundle’s Resources directory. If present, macOS activates the fonts at the specified path for use by the bundled app. The fonts are activated only for the bundled app and not for the system as a whole. The path itself should be specified as a relative directory of the bundle’s Resources directory. For example, if a directory of fonts was at the path /Applications/MyApp.app/Contents/Resources/Stuff/MyFonts/, you should specify the string Stuff/MyFonts/ for the value of this key.
The text was updated successfully, but these errors were encountered: