RobotoLight and bold problem with Chrome on MacOS

[claudiobosticco]

Hello, I see a strange behaviour of the RobotoLight font using Chrome on MacOS. No problem with Safari and FF.

If I go to this sample:
https://smartclient.com/smartclient-.../?id=helloForm
and modify it like this:

isc.DynamicForm.create({
    autoFocus: true,
    numCols: 3,
    items:[
        {
            type: "text",
            name: "you",
            title: "Enter your name",
            wrapTitle: false
        },
        {
            type: "text",
            name: "you2",
            title: "Enter your name",
            wrapTitle: false,
            required:true
        }
    ]
})

I don't see a big difference in the font rendering between the two titles (the 2nd formItem has required:true, so it's bold)



Note that the behaviour seems the same with 13.0 , 12.1 and even older builds I've tried. Actually I don't think it's a SmartClient bug.

I've installed a new clean version of Chrome 108.0.5359.71 on MacOS Ventura 13.0.1 as I initially thought it was a problem with some Chrome extension, but it hasn't changed.

I've tried two different MacOS machine with the same result.

If I change the font to plain Roboto, then I see clearly the difference between normal and bold.

Have you ever noticed this problem? Have you got an idea of what's the culprit?

[Isomorphic]

OK, we dug pretty deeply into this because, even though it's almost certainly a Chrome bug, at a glance it seems like maybe our software is doing something wrong.

First of all, we see the same - in every Windows browser, and in every other MacOS browser other than Chrome, the second title is more obviously bold and has wider letter spacing.

In MacOS Chrome, the same font is being used, and boldness is being applied, and Chrome is rendering it subtly differently, but you have to zoom in to be able to tell that the font is being rendered differently at all. Further, there is no letter spacing difference.

We checked to make sure we were not applying special CSS that could possibly cause this, and went as far as to create a standalone test with SmartClient completely omitted (which you can also look at: https://smartclient.com/fontWeightTest.jsp), and basically, we're not creating the problem, it seems that it has to be a Chrome bug.

We also tried, as a possible workaround, setting CSS font-weight to a numeric value (basically asking for "bolder than bold") but this had no effect. You can see this in the test case above.

Note also, we don't see an existing Chrome bug filed for this. We may file one, but we have a lot going on right now. If you file one, please let us know.

In the meantime, we have scheduled this to be looked at after another couple of Chrome releases. If they still haven't fixed it, we will evaluate what to do.

[claudiobosticco]

Hello, I see that the issue is still present. I think I notice it even more with the new Shiva skin (maybe due to the "minimal" design of grid headers).
Do you have an idea of how to proceed? Filing a Chrome bug or other?

[Isomorphic]

We decided to ask ChatGPT:

we're seeing an issue where, in Chrome on MacOS, the RobotoLight font, when rendered in bold, is barely distinguishable from non-bold. One has to zoom in to see the very slight difference in appearance. This problem does not happen for the same font on other MacOS browsers, and does not affect Windows Chrome (or any other Windows browser).

What could the problem be, and is there any workaround other than filing a Chrome bug?

No need to repeat the answer here, but basically, you could switch to Roboto Medium, perhaps only for bolded text, or there were a couple of really obscure CSS settings to try.

If you go down the road of filing a Chrome bug, feel free to grab source code from the fontWeightTest we created above. Also, please post the bug URL here - we'll have several people "star" it to try to get attention.

[claudiobosticco]

Hello, actually I've just discovered that someone has already filed the bug:
https://bugs.chromium.org/p/chromium...otolight&can=1

what do you think of the thread conclusions?

[Isomorphic]

That's very typical of what happens with Chrome bugs: severity is downplayed, clear bugs are re-defined as "expected" and then someone slaps a WontFix resolution on it.

We've done what we can: Support clarified that there is a real issue, and we had our CTO post a comment to add some oomph. However, from past experience, we expect that this is either ignored, or the developer digs in his heels, or it is assigned but never fixed.

We're just going to look for a different font. It may take some time, so if you end up finding a replacement you like, please let us know. This site:

https://www.typewolf.com/all-fonts

.. list some trending ones, although this will generally be showing fonts that are good for blogs and news sites rather than for UIs.