WinGet and font support

[denelon]

Hey all, I've started digging into what it would look like to support managing fonts using WinGet. I've reached out to a few folks to get some feedback on this, and I wanted to keep the "noise" out of the Issue:

• Support for installation of fonts #166

I don't think we want to treat them the same way we do with portable packages due to the way WinGet creates entries for portable apps like Microsoft.NuGet in Apps & Features.

I've been looking at a few different references like:

• How they get installed.
• How they are versioned.

I've also been thinking about the implications of adding them to the WinGet Community Repository and how that has implications on the size of the PreIndexed cache.

One of the more popular sites (Nerd Fonts) already has a decent collection of fonts for us to potentially evaluate when we get to the point of supporting an experimental feature for managing fonts.

Since we're likely to be enumerating over a directory "C:\Windows\Fonts" and each file can have its own version, I'm expecting some additional complexity when an upgrade to a font could represent downloading a set of files.

Thoughts?

[denelon]

I recently got informed about FontSetViewer.

[denelon]

I was also asked to include https://fonts.google.com/.

[lhecker]

Hey all, I'm one of the reached-out-to-persons. 😄 I work on font rendering for Windows Terminal and will try to help wherever I can.

When it comes to listing fonts, I would probably recommend listing them grouped by their typographic family name (DWRITE_FONT_PROPERTY_ID_TYPOGRAPHIC_FAMILY_NAME). Apart from the already mentioned https://github.com/fdwr/FontSetViewer tool (it has a few issues with DPI at the moment), the Personalization > Fonts section in the Settings app is probably also a great place to find reference code (internally).

My recommendation is to install fonts for all users, always (= C:\Windows\Fonts). Per-user fonts don't work with packaged apps, and the corresponding internal issue MSFT:42103854 has not been resolved yet and there doesn't seem to be traction yet to resolve it soon.
To install/uninstall them just add or delete them in that directory. Be careful not to delete any system fonts though. The Fonts control panel has code that prevents that, but I never checked how that's done (for instance, try to delete Consolas - it'll show a warning dialog). You can get file paths for installed fonts with something like that: https://github.com/microsoft/terminal/blob/baba406a074e792dd4486f4239ac4b3292f95a60/src/renderer/atlas/BackendD3D.cpp#L1309-L1340

The problem with that approach is that access to the directory is restricted to elevated processes. Explorer can install fonts there without an UAC prompt (if the user is an Admin account), because they use 642EF9D6-48A5-476B-919A-A507CFD02C0F, aka fontext.dll to circumvent all that.
This puts winget in a difficult spot: It either has the choice of fonts being broken in packaged apps (Windows Terminal for instance), or it requires elevation during installation.

[svrooij]

I would opt for installing for all users, we want the fonts to work in all tools installed and not just some because you did not want to do the uac.

[Alxandr]

winget also already does UAC prompts for a lot of installations, so I don't think this is a major issue.

[denelon]

There is a comment from @RobCannon with 16 👍at current count not to "require" elevation. Unfortunately, packaged applications (MSIX based installers) require the font to be installed for the machine.

Since WinGet does have the context of scope, we should be able to figure something out such that fonts can be installed as user or for the machine. I'm expecting we'll want to have some kind of informational message to help users understand the caveats with packaged applications.

[JohnMcPMS]

My initial thoughts on the interaction here is to treat fonts as a separate vertical for logical containment. A separate repo might be too much (aka winget-fonts), but placing them in their own directory in winget-pkgs would be sufficient to create another namespace for them. They would end up in their own source, which would be marked with a new category field, so that it requires direct mention from normal commands (winget install -s fonts "Cascadia Code") but would be implied by the category specific commands. I want to build a logical wall for the community repo but keep the client largely unaware so that private repos can easily contain fonts as desired by their operators.

On winget.exe I would continue with the category separation. An entire fonts subcommand structure would be created, which would implicitly use the fonts category sources and filter the installed items to only fonts. All of the package management commands would be supported, and the only difference is in how the installed and available items are filtered. Alternatively (or in addition), the existing commands could have a new --category fonts added instead. Functionally these would be identical.

Programmatic interfaces (COM API and PowerShell) would have a new installed fonts catalog, as well as a few new properties to expose categories. Beyond the catalog selection, the existing API surface would not need to be changed (except to potentially add properties specific to fonts if needed).

I would expect that my recent work supporting side-by-side might play in here to better allow grouping of font families while still allowing for fine control if desired.

There are many more implementation details that would need to be considered, but much of that is not necessarily important to end users/consumers of our interfaces.

[Karl-WE]

I believe this is a cool idea.

(1) Use cases

• From a use case perspective it could be niche though
  There are many fonts available and quite some already inbox.

• Are there still security issues that could come with malformed fonts, or is this a thing of the past? It's in a system / well-known folder and often requires admin permissions as mentioned.

• Users, opposed to new Settings app cannot preview fonts / try out.

• adding fonts to Windows to match Corporate Identity requirements.
  Could be used in Office Apps, bginfo

• Windows LOB Apps etc., some apps use specific fonts or barcode fonts

The last time I had to do this for a customer CI objective we end up using a small tool for thats.
This was back in Windows Server 2016.
Customer did not want to modify the WIM file or use predefined / sysprep images.

• Necessary font requirements for developing Apps, (web) design, Marketing, Blogging

• Fonts to support uncommon, non alphabetic characters

• Fevelopers that require special fonts for application development.

@denelon your link to install fonts is still correct but overly improved by Windows Settings Uri ms-settings:fonts
This allow per user installation, as well as simple drag and drop, improved UX (older not changed since Windows 9x)

(2) Remote related, default fonts and protection

• Microsoft is not always consistent about fonts. Consolas and Cascadia Code are great examples.
  Latter is default font for Windows Terminal and Visual Studio Code.
  But unfortunately not for ConsoleHost (cmd / PS 5.1), Notepad.exe / Notepad UWP, ISE (deprecated)
  Checked latest with Windows Server 2025 preview (Consolas comes preinstalled).

I wished Cascadia Code would be replacing consolas and Courier New as a new default for all fixed fonts in Windows.

• As stated we need to protect the removal of certain fonts or things will break.

(3) Benefits of WinGet and font management

• Easier deployment for Windows Clients, including AVD and Windows Server 2025.

Currently deployment of fonts is not that easy. We ended up to use a helper tool as Windows native Tools didn't do the trick for remote deployment of fonts at scale.
Just copying files to c:\windows\fonts will not register them correctly.

(4) potential (legal) issues

Fonts are often underlying licensing and certainly copyright.
It should be considered which sources are added to the winget packages or eventually allow special repos for fonts only in addition to app repos.

(5) performance and clutter

Winget search should not be affected by adding fonts in terms of results, consistenty and if possible speed, when searching for apps.

Could this be solved by using a new repo for fonts, which is searched last or adding tags?

With 4 and 5, I support the comments and thoughts of @JohnMcPMS .

[Karl-WE]

Revised structure of my former reply and added more aspects

[denelon]

Similar to the way we have /manifests/<char>/<publisher>/<package>, I think we might do something like /<fonts>/<char>/<publisher>/<package> in the winget-pkgs repository so logically separate fonts from "Apps/Packages".

[SpecterShell]

WinGet should throw an error if the fonts are being used by other programs.