Squarespace based podcast blog – font rendering issue

[KlarkKentThe3rd]

Might as well. For the last few releases of PM I had this specific podcast website display text in a pale and thin manner. Attached are screenshots of pale/thin (PM) and contrasty/thick (Waterfox). Website link: http://www.supermarcatobros.com/podcast ... tle-themes

Based on what scripts have to run, the website is built with Squarespace. I am using PM 29.2.1

Browser Console gives me this:

Code: Select all

yui: NOT loaded: squarespace-polyfiller_modern  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594
yui: NOT loaded: squarespace-polyfiller_legacy  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594
yui: NOT loaded: squarespace-moment_js_vendor  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594
yui: NOT loaded: squarespace-cldr_resource_pack  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594
yui: NOT loaded: squarespace-common_vendors_stable  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594
yui: NOT loaded: squarespace-common_vendors  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594
yui: NOT loaded: squarespace-performance  
common-vendors-stable-692c8190cb7f9d38c3f12-min.en-US.js:1:36594

[Moonchild]

Here's what it looks like for me:

FireShot Pro Screen Capture #276 - 'Episode 471_ Battle Themes — Super Marcato Bros_' - www_supermarcatobros_com_podcast_2021_6_6_episode-471-battle-themes.jpg

Which is fine and perfectly readable (and actually looks better than FireChrome's rendering IMO).
If you tweaked contrast parameters in Pale Moon or are overriding font weights, then this might be the result. The font used (Raleway) is rather anaemic.

[KlarkKentThe3rd]

No, cannot remember doing any overriding.

[BenFenner]

I'm also seeing the high-contrast rendering (as high contrast as one can get with a medium-shaded background like the one used) on Windows 7.
Font faces can be quite different on Linux, so I can go check that and report back.

Edit: Different font on Linux, but still black text (or nearly so). Something is likely up with your particular setup...

[Moonchild]

This is the point where the output of help -> troubleshooting information might be helpful.

[coffeebreak]

text in a pale and thin manner

I don't see this either (using PM 29.2.1, Win 7 x86).

For me the text looks like that in Moonchild's screenshot.

supermarcatobros-fonts.png

Btw, I do see the same console messages as you posted, but given how fonts display here, they are presumably not relevant.

[RealityRipple]

It's using a Google-hosted font called Raleway. If "Allow pages to choose their own fonts" is unchecked (under Advanced in the screenshot you posted), or if you have an adblocker or cross-origin css blocker of some sort enabled, the font's not gonna load. You should also check the Network tab of the developer tools console to make sure all the requests to "fonts.googleapis.com" and "fonts.gstatic.com" succeeded.

[Moonchild]

If "Allow pages to choose their own fonts" is unchecked (under Advanced in the screenshot you posted), or if you have an adblocker or cross-origin cs....

irrelevant because you can clearly see in the screenshot that the correct webfont is in use.

[KlarkKentThe3rd]

Perhaps this is entirely the fault of my particular "build". And if that is the case, there is nothing Moonchild can do about it.

[RealityRipple]

If "Allow pages to choose their own fonts" is unchecked (under Advanced in the screenshot you posted), or if you have an adblocker or cross-origin cs....

irrelevant because you can clearly see in the screenshot that the correct webfont is in use.

Google separates fonts by their weight and whether or not they're italic. If the weight the page uses fails to load, it might fall back to another one. The site in question loads weights from 100 to 700, but seems to primarily use 500. The picture looks like it fell back to 100.

[KlarkKentThe3rd]

If the weight the page uses fails to load, it might fall back to another one. The site in question loads weights from 100 to 700, but seems to primarily use 500. The picture looks like it fell back to 100.

You might be on to something.

[Moonchild]

Doesn't make much sense to me. Why would something be blocking 1 font variant but not another from the same service?

[BenFenner]

As an experiment, I used the dev tools to change the font weight from 500 to 100 and it reproduced the OP's problem.

Edit: Well nearly so. It looks nearly identical, except the word "Battle!" on my page is still bold/strong... That isn't the case in the OP's first screenshot...

[RealityRipple]

The word "Battle" next to Xenoblade Chronicle's 2's battle theme is separately bolded without using a number, meaning it's using 700 instead of 500.

The reasoning why one might be loaded while another (or others) aren't could be either because the CSS (or the URL) got mangled, or because one or more of the fonts' filenames have characters that are being blocked. I often run into issues on websites where an image will have a hexadecimal name and will get blocked just because the first two characters of the name are "AD". In Google fonts' case, it's base64, but it's still possible that something in "1Ptxg8zYS_SKggPN4iEgvnHyvveLxVvao7CIPrE" was acceptable while "1Ptxg8zYS_SKggPN4iEgvnHyvveLxVuEorCIPrE" was blocked. Or it could literally have been randomly caused by timeout or a prematurely closed connection and then cached that way. But a mangled URL would be the most straightforward way I see, mostly because each weight is separated by semicolon: if something stripped everything after that semicolon from the URL, it'd only load 100 weight.