IssueTracker

google-sans* and google-sans-text* differ only in 'opsz' and that is expected. Both the styles/variations are part of GoogleSans-Regular.ttf. Can you compare 'G' in google-sans-medium and google-sans-text-medium? That should give us an idea if the right variation is being rendered. https://screenshot.googleplex.com/3VAteCSbxN3xM56.png shows the difference.

The Google Sans to Google Sans Text variable font style transition is defined on the opsz axis and takes place at the 17/18 transition point (>= 18 is GS, < 18 is GST). There are indeed letterform changes along the opsz axis transition. The easiest one to use for GS vs. GST comparisons is the upper case G (U+0047). It has a round logo form in GS and a more condensed shape with a spur on the right side heading down to the baseline in GST. The configurations in #2 appear to be the correct set of axis values for Roman Regular weight GS (opsz 18) and GST (opsz 17).

The axis values for GS Text Medium weight should be:

<axis tag="GRAD" stylevalue="0"/>
<axis tag="opsz" stylevalue="17.0"/>
<axis tag="wght" stylevalue="500"/>

and use the GoogleSans-Regular.ttf variable font for Roman and GoogleSans-Italic.ttf variable font for Italic. It looks like they are properly defined for google-sans-text-medium in the fonts_customization.xml file that you linked in #3.

Is the concern here that you are seeing file paths that suggest you are using "Google Sans" rather than "Google Sans Text", or that you are seeing text formatted with the "Google Sans" style rather than the "Google Sans Text" style?

Ack. Thank you for the explination.

I've confirmed the font renders correctly.

Attached screenshot of basic Compose app

    Column {
        Text(
            text = "GGGGGG google-sans",
            fontSize = 60.sp,
            fontFamily = FontFamily(
                Font(
                    DeviceFontFamilyName("google-sans"),
                )
            )
        )
        Text(
            text = "GGGGG google-sans-text",
            fontSize = 60.sp,
            fontFamily = FontFamily(
                Font(
                    DeviceFontFamilyName("google-sans-text"),
                )
            )
        )
    }

Font file

Same result for google-sans-text-medium

Text(
            text = "GGGGG google-sans-text-medium",
            fontSize = 60.sp,
            fontFamily = FontFamily(
                Font(
                    DeviceFontFamilyName("google-sans-text-medium"),
                )
            )
        )

I've confirmed on Pixel 6 that "google-sans-text-medium" loads a GS text font - see attached.

Can you get a minimal repro for this one? It looks likely that it could just be using the wrong font at that application.

Reproduced by loading in background. Appears related to DeviceFontFamilyName variation setting from a background thread leaking somehow.

For Google Sans Text please specialize the opsz when loading it.

You can either

1. Disable load-time font variation settings

@OptIn(ExperimentalTextApi::class)
val GoogleSansText500Medium = Font(
    DeviceFontFamilyName("google-sans-text-medium"),
    weight = FontWeight.W500,
    variationSettings = FontVariation.Settings() /* don't specialize font variation, leaving opsz alone */
)

2. Intentionally specialize the font variation settings, including explicit opsz

@OptIn(ExperimentalTextApi::class)
val GoogleSansText500Medium = Font(
    DeviceFontFamilyName("google-sans-text-medium"),
    weight = FontWeight.W500,
    variationSettings = FontVariation.Settings(
        FontWeight.W500,
        FontStyle.Companion.Normal,
        // opsz <=17f for Google Sans Text
        // opsz >=18f for Google Sans
        FontVariation.Setting("opsz", 17f)  
    )
)

What's going on

When opsz is not provided, the default behavior of specializing variation settings to (Weight Style) causes opsz to be reset to the default value, which is "Google Sans"

By explicitly skipping variation settings, or setting opsz you're ensuring that either (1) the system loaded typeface or (2) the desired specialization is used exactly.

This bug was linked in a change in the following release(s):

• androidx.compose.ui:ui-text:1.3.0-rc01