Skip to content
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

Closed
baconpaul opened this issue Jan 5, 2019 · 16 comments
Closed

Use a custom and uniform font #214

baconpaul opened this issue Jan 5, 2019 · 16 comments
Labels
Feature Request New feature request

Comments

@baconpaul
Copy link
Collaborator

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.

@baconpaul baconpaul added the Feature Request New feature request label Jan 5, 2019
@jarkkojs
Copy link
Collaborator

jarkkojs commented Jan 8, 2019

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?

@jarkkojs
Copy link
Collaborator

jarkkojs commented Jan 8, 2019

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.

@kurasu
Copy link
Collaborator

kurasu commented Jan 8, 2019

Lato is perfect, its very pretty and and renders digits at constant size so its very well suited to numerical diplays.

@jsakkine
I'd assume VSTGUI just uses the platform font rendering, nothing custom. We don't want a fixed-size font for stylistic reasons, and any optimizations needed can be done at a string-level instead of character level. But since we're hardly doing any text rendering at real-time intervals anyway (apart form the text-popup on mouse-drag) I don't see how this sholud ever be an issue.

@baconpaul
Copy link
Collaborator Author

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".

@jarkkojs
Copy link
Collaborator

jarkkojs commented Jan 8, 2019

OK, cool. Where is the text/number rendering code located for on-screen display?

@baconpaul
Copy link
Collaborator Author

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?

@jarkkojs
Copy link
Collaborator

jarkkojs commented Jan 8, 2019

Thanks. Will look into this at some point.

@baconpaul
Copy link
Collaborator Author

Cool. Happy to hop on slack sometime to tell you what I’ve learned about vstgui so far if that’s of interest

baconpaul added a commit to baconpaul/surge that referenced this issue Jan 18, 2019
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.
@baconpaul
Copy link
Collaborator Author

Well just a bit of experimenting tells me ATSAPplicationFont doesn't work for .component bundles.

@baconpaul
Copy link
Collaborator Author

@baconpaul
Copy link
Collaborator Author

@baconpaul
Copy link
Collaborator Author

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

@baconpaul
Copy link
Collaborator Author

screen shot 2019-02-08 at 5 04 25 pm

I don't have Lato installed on my mac, but here's a surge running with lato that it loads from the bundle.

Windows next.

@baconpaul
Copy link
Collaborator Author

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.

baconpaul added a commit to baconpaul/surge that referenced this issue Feb 9, 2019
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
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 9, 2019
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
@baconpaul
Copy link
Collaborator Author

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.

@baconpaul
Copy link
Collaborator Author

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
2: We can make local subclasses of CFontDesc which allow us to reset the platform font, and then of the IPlatformFont for each of linux and windows.

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.

baconpaul added a commit to baconpaul/surge that referenced this issue Feb 9, 2019
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
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 9, 2019
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
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 10, 2019
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
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 10, 2019
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
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 11, 2019
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.
baconpaul added a commit to baconpaul/surge that referenced this issue Feb 14, 2019
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.
baconpaul added a commit to baconpaul/surge that referenced this issue Jul 10, 2019
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
baconpaul added a commit to baconpaul/surge that referenced this issue Jul 10, 2019
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request New feature request
Projects
None yet
Development

No branches or pull requests

3 participants