feat(fonts): getFontData

[florian-lefebvre]

Preview release

Install:

pnpm i https://pkg.pr.new/astro@13811

Use:

import { getFontData } from 'astro:assets'

const data = getFontData('--font-roboto')

Changes

• Requested on the Stage 3 RFC
• Adds a new getFontData(cssVariable) function exported from astro:assets to allow retrieving data relative for a given font file. We only expose a few properties and will add more as they are requested
• I followed a similar pattern as getImage to implement it. It's a bit tricky because it's a virtual module which depends on another
• I also renamed the FontFamily type to CssVariable

Testing

Updated unit and integration tests

Docs

• Changeset
• Docs: feat: getFontData() docs#12345
• RFC: withastro/roadmap@75b5810 (#1039)

[changeset-bot]

🦋 Changeset detected

Latest commit: 920008d

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

CodSpeed Performance Report

Merging #13811 will not alter performance

_{Comparing feat/fonts-retrieve-data (920008d) with main (a601186)}

Summary

✅ 6 untouched

[pkg-pr-new]

astro

npm i https://pkg.pr.new/astro@13811

@astrojs/cloudflare

npm i https://pkg.pr.new/@astrojs/cloudflare@13811

@astrojs/netlify

npm i https://pkg.pr.new/@astrojs/netlify@13811

@astrojs/node

npm i https://pkg.pr.new/@astrojs/node@13811

@astrojs/vercel

npm i https://pkg.pr.new/@astrojs/vercel@13811

commit: 324c35c

[florian-lefebvre]

@delucis shared it would be nice to have a way to retrieve buffers directly. It doesn't need to block this proposal but I'm taking note

[tanishqmanuja]

Hey @florian-lefebvre, this works but isn't the API exposed to the user too verbose for getting the font url ?

const fontSrcUrl = getFontData("--ff-pixelated")[0].src[0].url;

[florian-lefebvre]

We are talking about it and will probably expose a more generic API. I know it's verbose but there are good reasons:

• a font family is made of several font faces (first array)
• a font face is made of several sources (nested array)

[tanishqmanuja]

Yeah I understand that aspect.

Also user could wrap the implementation for their specific use case... like

function getAstroFontPath(cssVariable: CssVariable): string {
  const data = getFontData(cssVariable);
  if (data.length === 0) {
    throw new Error(`No data for ${cssVariable}`);
  }

  const src = data[0].src[0];
  if (!src) {
    throw new Error(`No src for ${cssVariable}`);
  }

  return src.url;
}

[delucis]

Yeah, @florian-lefebvre and I were chatting about it and whether it wouldn’t be more helpful for your use case to just have access directly to the Astro-generated CSS @tanishqmanuja? I guess in the end otherwise you’re trying to regenerate that yourself with your own logic?

[tanishqmanuja]

@delucis that would be the perfect solution, your guess is correct...
https://github.com/tanishqmanuja/astro.portfolio/blob/d5260b82e160c156716c96308f6b4c0a40bc3363/src/pages/giscus/_theme.css#L7C1-L13C2

EDIT:
Having said that, I think my use case could be a one-of use case, getting the URL is more common.

[plttn]

Yeah, my two cents is the above feels very wordy (especially if you're using variable fonts in which case it's currently difficult to figure out which array member you'd use). Right now my use of this is also in Satori, with the following function to get buffers from fonts stored in my repo (which are duplicates of what I have through the font API)

const fetchFonts = async () => {
  // Regular Font
  const fontFileRegular = await fs.readFile("fonts/SpaceGrotesk-Regular.ttf");
  const fontRegular: ArrayBuffer = fontFileRegular.buffer as ArrayBuffer;

  // Bold Font
  const fontFileBold = await fs.readFile("fonts/SpaceGrotesk-Bold.ttf");
  const fontBold: ArrayBuffer = fontFileBold.buffer as ArrayBuffer;

  return { fontRegular, fontBold };
};

In a perfect blue sky world, the call would look something like

const fontRegular: ArrayBuffer = getFontBuffer("--font-space-grotesk", "regular");

Thanks for all your work with the Font API though, it's been great overall!

[ascorbic]

Could the public type have a better name?

[florian-lefebvre]

Which one, ConsumableMap? It is not really public since it's not exported directly

[ascorbic]

Much better!

[ascorbic]

I am slightly in two minds about the function name, because people might expect it to get the raw data, but I can't think of a better one.

[florian-lefebvre]

Yeah for the record we're not passing the full data (typed as unifont.FontFaceData[]) because:

• I don't want to include a 3rd party type in there
• The least properties we include by default, the easier it is to change internal structure as needed once stable

[sarah11918]

Yay! Left some changeset thoughts, Florian!

[sarah11918]

Looking good! Just two quick code formatting fixes in the error message from me!