Font metrics covering all available font weights

[DamianGlowala]

Weights of the same font differ in metrics, hence impacting the usefulness of this library for any other weight than normal. Would it be possible to consider extracting separate metrics for each font weight?

Context:
unjs/fontaine#53 (comment)

[michaeltaranto]

Hey Damian, thanks for the feedback. In terms of the library's usefulness, I assume you are referring to using the metrics with the createFontStack API?

We are about to land an substantial upgrade to the unpack and metrics library to add support for character sets beyond basic Latin. This work will provide the foundations from a data structure perspective to be able to handle variants, e.g. weight, italics, etc.

As xWidthAvg is a computed value that is not available in the tables internally, we are have had to consider how best to model the data across character sets and frequencies, weights, and other variants.

Hopefully have more to share on this very soon

[DamianGlowala]

Really appreciate your update on this (both here and in the unjs/fontaine issue)!

Personally, I think this might have even wider impact. I am currently using the following library:
https://github.com/stormwarning/tailwindcss-capsize

It generates Tailwind CSS leading-trim utility classes, which help design predictable UIs by removing the extra space from text bounding box. In the project I am working on I noticed that e.g. for a Lato font of a normal weight it works perfectly, but any lighter/bolder weights are slightly off in terms of measurements. This was another reason for creating this issue (alongside the unjs/fontaine one).

Ideally, once we have all the metrics for different font weights, the above library can be tweaked to produce a set of Tailwind CSS utilities covering all the weights which will allow (nearly) pixel perfect trimming.

Exciting times, looking forward to it :)

[michaeltaranto]

Thanks for the additional context. The point you make around leading trimming is interesting. My thinking has been that having mixed weights alongside each other (e.g. emphasized words in a sentence), you wouldn't want to trim one word more than the other.

I would be curious how the text-box-trim spec intends to handle this. Something to ponder maybe.