SIM - Relay Response - CSS - Fonts

[dan_yyz]

Hello,

I think I know the answer to my issue from reading through the forums but hope to clarify. My SIM / relay response page works just fine. However, I'd like to use my website fonts on it, and they are not loading, even though I used an absolute path to them.

From reading here, it seems that because they are not HTTPS, they won't get processed through the transact.dll.

Is that correct? It seems like an unfortunate performance penalty just to invoke HTTPS for one or two fonts to match my site - any workaround possible? The relay response URL is: http://www.followerof.com/transaction_response.asp .

The CSS that is not working in the relay response URL when it lands after a transaction, is below.

Thanks,

Dan

@font-face {
    font-family:AmbleLight;
    src: url('http://www.followerof.com/Amble-Light-webfont.eot');
    src: url('http://www.followerof.com/Amble-Light-webfont.eot?#iefix') format('embedded-opentype'),
         url('http://www.followerof.com/Amble-Light-webfont.woff') format('woff'),
         url('http://www.followerof.com/Amble-Light-webfont.ttf') format('truetype'),
         url('http://www.followerof.com/Amble-Light-webfont.svg#AmbleLight') format('svg');
    font-weight: normal;
    font-style: normal;

}

[RaynorC1emen7]

In FF, did they show any error in

Tools - Web Developer - Web Console

[16:03:02.216] downloadable font: download failed (font-family: "AmbleLight" style:normal weight:normal stretch:normal src index:1): bad URI or cross-site access not allowed
source: http://www.followerof.com/Amble-Light-webfont.woff

You could probably use javascript to redirect back to your site to display the response.

[dan_yyz]

Hi there,

Yes:

[17:03:23.744] GET http://www.followerof.com/Amble-Regular-webfont.woff [HTTP/1.1 404 Not Found] - it also said, [Mixed Content]

and:

[17:03:23.911] downloadable font: download failed (font-family: "AmbleRegular" style:normal weight:normal stretch:normal src index:1): bad URI or cross-site access not allowed
source: http://www.followerof.com/Amble-Regular-webfont.woff

[17:03:24.165] downloadable font: download failed (font-family: "AmbleRegular" style:normal weight:normal stretch:normal src index:2): bad URI or cross-site access not allowed
source: http://www.followerof.com/Amble-Regular-webfont.ttf

[17:03:24.165] downloadable font: no supported format found (font-family: "AmbleRegular" style:normal weight:normal stretch:normal src index:4)
source: (end of source list)

[Perry121]

You can also use https://textandfonts.com/aesthetic-text-generator/ for generating unlimited useful fonts for your website and social media use as well.

[jamessteve]

Hii, I tried to use the method u mentioned above:  https://textandfonts.com/projectqt-aesthetic-text-generator/, but it doesn't work, please help!!!

[danielcarter]

Yes, you've correctly diagnosed the problem. A browser will block insecure HTTP content like a font from loading on a secure HTTPS page.

The only way to fix this is to host your fonts on an HTTPS server as well. There is no safe workaround because this is a standard security feature to protect users. The performance impact of serving a few fonts over HTTPS is negligible and well worth the security.

[codex174]

You're correct — mixed content restrictions are almost certainly the issue. Browsers block HTTP font files from loading on HTTPS pages (and vice versa in some cases), which is why your custom web fonts aren't rendering on the relay response page and it's falling back to default system fonts.

The simplest fix is to host your font files over HTTPS and update the `@font-face` `src` URLs to use `https://` or protocol-relative `//` paths (e.g., `src: url('//www.followerof.com/fonts/yourfont.woff2')`). That way the fonts load regardless of whether the page is HTTP or HTTPS. Alternatively, if you can't switch to HTTPS, use a reliable web-safe fallback font stack (like `Arial, Helvetica, sans-serif`) so the text at least renders consistently instead of breaking entirely.

[ethancarter1998]

Good diagnosis on your end — mixed content blocking is exactly why your custom fonts aren't loading on the relay response page. The cleanest fix is to serve your font files over HTTPS and use protocol-relative URLs (`//yourdomain.com/fonts/font.woff2`) in your `@font-face` declarations, which lets the text render with your branded font regardless of the page protocol. If HTTPS isn't an option, at least define a strong fallback font stack like `'YourFont', Arial, Helvetica, sans-serif` so the text stays visually consistent with your main site instead of defaulting to ugly system fonts.

[masonbrooks074]

That worked perfectly, thanks! Switched the `@font-face` URLs to protocol-relative paths and the custom fonts now load cleanly on the relay response page, text finally matches the rest of my site's branding. Really appreciate the tip about the fallback font stack too; added `Arial, Helvetica, sans-serif` as a safety net so text rendering stays consistent even if the font files ever fail to load.