Website updated without Font Metrics about capsize HOT 11 CLOSED

@jps @Vanals If it helps, we've also found it useful to use the OpenType Font Inspector to manually grab metrics when roadtesting different fonts across themes.

from capsize.

I'm using the React Native implementation and also need to look up the font metrics using the website. Would love to see an option to see these values directly on the website.

from capsize.

I work on the same team as @Vanals 👋 Just to add a bit more context about our usage.

We are building a multi brand design system, a large part of our value add is we allow brands to bring their own themes that will then style all the components.

A feature of our system is text cropping, thanks to your work in this area 😃.

We are looking to streamline the process of creating a theme as much as possible to reduce friction, designers do this in via Figma, it's then exported into code.

At present developers will need to add font metrics to this theme manually. We do detail this in our documentation

I think we need to explore a couple of things

1. We can look at if there is any way to get access to the fonts and run unpack inside the browser in a Figma plugin, this would be the ideal and possibly remove the manual step previously mentioned.
2. If this is not possible we could look at unpack so it can be executed by a developer via npx or via our site to get the metrics out. This is essentially what we were using your site for previously.

from capsize.

@michaeltaranto Thank you for giving of your time to clarify things. Really appreciate this. I will try to find a solution that work for us.

from capsize.

Hey 👋 , interesting to hear you have a workflow around using the site, thanks for sharing!

I definitely feel that we could speed up the flow by using the unpack package and in particular the fromFile function. Was there a reason to not adopt a more streamlined flow?

A goal is to make these metrics more of an internal detail where possible so consumers only need to explicitly set them as an advanced use case.

from capsize.

I think would be good to explore the use of the package and eventually implement it, but is going to take time and at the moment this is a breaking change for us 😕 . We would need more time, that's why would be good for us if you can keep the metrics in the website and have a more smooth transition.

from capsize.

Yeah, as I said I second this. It is very useful to have and at the moment broke our flow.

from capsize.

@jps Thanks for sharing this detail! I always enjoy hearing about other peoples design/dev workflows. Sounds like you have got a flow that works for your team which is great.

I would have to say, I feel like I am still missing something as the code block demonstrated in the Code section of Text Crop looks like it would benefit greatly by being able to install or extract the values programatically using the metrics or unpack packages.

Given where things are at, I'm not super keen on rushing the metrics back into the site, but you can maintain your existing process by using the preview deployment of the site before the recent update.

@olach see above, but again even with the react-native implementation you should be able to install or extract the metrics without needing direct access.

from capsize.

@michaeltaranto I will look into extracting the metrics programmatically as you suggest.

But, and you must correct me if I'm wrong: if I'm using the fromFile function, is it correct that this extraction is done on the client on every page load?

If that is the case, that seems really unnecessary and a waste of computing resources to let this extraction of the metrics happen on every page load on the client device. I always strive to ship less code to the client user, not more.

I guess it's possible to create a build script instead that extract these metrics on project build instead. But that is another build task that has to be added to the (already) complex build systems needed for todays web development.

Just as when we are choosing a font for a project, adding the font files manually to a folder, and setting the sizing values for the font in code, it would be naturally to also hardcode these font metrics once and for all and then forget them.

from capsize.

@olach I would highly recommend against running that code in the client at runtime yes.

The metrics package can hand you an is object of metrics for a given font, so you can import from there and it should be the same as of hand written.

The unpack package is ideally run as a build step of sorts. Whether that is every time you build your app or if you have a script that builds your typography theme is totally up to you.

The unpack package would only make sense if the font you are using does not exist in the metrics package.

from capsize.

@Vanals @olach @jps FYI we have now added the metrics as a first class part of the site. After selecting a font, you can now choose the JSON tab to see the metics

from capsize.