Some email clients don't support web fonts, and all the proposed solutions I've seen for this are to force a backup font like Arial that's supported by the client. My problem is that I need the default web font font to show up because it is a barcode font.
Any workarounds to this?
You must create an image to ensure the barcode remains the same across all email environments.
You should insert it from a hosted location that is publicly accessible, rather than using Base-64 or CID methods (not fully supported across email environments - see https://www.caniemail.com/features/image-base64/)
e.g.:
<img src="https://webserver.com/image/barcode-34234234234234.png" width="200" alt="Barcode with number 13425245452" />
Related
I'm trying to send an email with an embedded image using generated HTML in the backend,
and I see that every email client is behaving differently.
Outlook only supports base64 format, and Gmail doesn't.
Gmail supports a regular image src, and also a background image, while Outlook doesn't.
I'm wondering if there is a generic solution for this issue
Thanks.
Not really. Different email clients support different things at different levels. You can have a look at caniemail.com for support details across popular email clients. For example:
background-image
base64 image format
A regular <img src> pointing to an hosted image usually works well, though.
I am currently working on send emails with image files included; they need to display as PNGs. My plan is to host the images on a server and then link them in the email. However, I am unsure of if I should send the emails as the PNGs themselves or if I should encode them to base64 before I send them. What is the best practice?
Thanks!
Best practice is to reference external PNG, JPG, and JPG files.
base64 encoded images are not well supported in email. They aren't supported in most web email clients (including Gmail) and are completely blocked in Outlook. Even for the small clients that do support embedded images, file size can quickly become a problem. Gmail App (iOS, Android) and Outlook (iOS) truncate email messages whose file size exceeds 102KB. Remotely referenced images (Eg. <img src="http://www.website.com/image.png"> do not count towards the email's file size, but base64 encoded images do and can quickly blow out an email's file size past the 102KB limit. Just something else to consider.
Most html emails feature images hosted on an external web site. This gets around the problem with some email clients that will not download an attachment until directed by you.
In the case of Email Service Providers (ESP) like Mailchimp or Salesforce Marketing Cloud (Exact Target), they host many of the images when you use their services. You could just as easily host them elsewhere.
Good luck.
My code has this:
<link href='//fonts.googleapis.com/css?family=Source+Sans+Pro:300,400,600,700' rel='stylesheet' type='text/css'>
<link href='//fonts.googleapis.com/css?family=Source+Code+Pro' rel='stylesheet' type='text/css'>
But I am sometimes finding that the googleapis is slow in my region. Can I host these fonts from my own server?
Yes you can. But doing it is a bit more complicated than saving CSS and the font files on your server.
The thing is, different Browsers use different font formats. Google solved this by delivering CSS rules with different font files depending on the user agent.
To support all browsers you will need the font files in TTF, WOFF, WOFF2, EOT and SVG format. But Google makes it unnecessarily hard to download the fonts files. From the google fonts site you can only download the fonts as TTF.
Also you will need cross browser CSS rules since you probably can not easily implement the user agent detection on your side.
To retrieve all formats you need to request the CSS file from Google with different user agents. Here is an outdated blog article listing some of the user agent strings to use. In the meantime WOFF2 was added and to actually get EOT you now need to send an IE6 user agent. IE7+ now will result in WOFF.
You can use the tool http://www.localfont.com/ to easily download all font formats and the corresponding X-Browser CSS.
Quick answer: YES
A quick googling revealed me these information.
Info Pages:
http://www.google.com/fonts/specimen/Source+Sans+Pro
https://www.google.com/fonts/specimen/Source+Code+Pro
They both are under the SIL Open Font License, 1.1
And this license do not impose much restrictions and allows you to host the font on your website.
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ofl-faq_web#23261834
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=ofl-faq_web#c26665c2
you have to host the css files on your server , and also you have to write the code is it fails to load from the server then it pick up from some local storage or you have provide another server link .
yes you can.
marked in red in the top right corner of google fonts there is a download link.
source:
https://code.google.com/p/googlefontdirectory/
I'm trying to do a signature in HTML using images that are encoded in base 64 data URLs.
Here's an example:
<img src="data:image/png;base64,iVBORw0KGgoAAAAN...kJggg==">
It's working nice with mail software as Mail on Mac or Thunderbird but it's not working with webmail such as gmail, outlook, roundcube , hotmail ...
Have you any idea how to make it work ?
I really want to put those images directly in the source code, it's more practical.
simple answer?
You can't. Gmail, outlook etc will ignore base64 images.
Look at this site to learn more about this
So based on our results, it is clearly not worth using embedded images in your emails. All you will be doing is forcing people to download encoded images that they will not be able to view.
I’m using embedded SVG, here is why:
It looks nice (vector graphics work well for logos).
No attachment (even images mailed as so called hidden email attachments are visible as such in many email clients).
No additional http request (works offline, once downloaded).
No “Do you want to load the images..” question.
It’s ok for me, if it doesn’t display in Gmail and Outlook. It’s kind of graceful degradation.
But if you really want to display images in Gmail and Outlook, you will need to load these via HTTP.
The guy from CSS-tricks has a nice guide on SVG in email: https://css-tricks.com/a-guide-on-svg-support-in-email/
The final solution is the following:
/* Resize an element that has a width and height of zero to full size */
.showy {
height: 100% !important;
width: 100% !important;
}
<!-- Image: SVG -->
<img class="showy" width="0" height="0" src="my-image.svg">
<!-- Image: JPG -->
<img class="no-showy" src="my-image.jpg">
But I personally don’t like it, because I don’t want a client to ask the user if he wants to load additional resources.
I am supporting a system which sends an automatic populated email alert. I have rendered the page using a combination of CSS and html. The alert is sent from a system called Salesforce. My problem is, I have never owned a blackberry, and don't have access to one for testing purposes, but I know the alert looks like crap on it.
It seems to be reading the page as plain text, after rendering it and stripping all styles, tables etc. What considerations should I employ the increase the readibility of the alert on a blackberry.
To start with, in order to see HTML rendered e-mail on a BlackBerry simulator, no matter the model, the simulator must run off of a BES connection (corporate BlackBerry server), as the included ESS (the software POP/SMTP proxy app that allows you to test BlackBerry e-mail services locally), does not support HTML e-mail.
Alternatively, if you have no access to BES, you can still test HTML e-mail rendering with BIS (personal internet connection), but you would need to do so on a real device. You can build a program fairly quickly which listens to incoming e-mail on the device an then delivers the original source of the incoming e-mail to you for debugging.
That being said, the older models of BlackBerry (around RIM OS 4.1), do not support HTML e-mail. If they receive HTML e-mail, they will display the full HTML source code, tags and all.
As of RIM OS 4.5, HTML support has been implemented in the BlackBerry e-mail application. In these cases, if the device receives an HTML message, it will attempt to display the HTML rendered format, as best as it can.
If the device cannot render the HTML for whatever reason (such as if this is a simulator running with ESS), and the message is a MIME hybrid, where it contains both HTML and text-only parts in one message, the device will display the text-only version of the e-mail. If the e-mail message is HTML only, and doesn't contain a text-only equivalent in the same e-mail, the device will attempt to strip out the HTML bits and tags and such, and will attempt to present the HTML message as it's own text-only version.
One testing option would be to run the BlackBerry emulators. Getting email on to them is quite tricky, but you can at least use the browser to test the rendering if you set the message up as a web page.
I'm not convinced by joshperry's comment that the rendering is the same across browser and email app, but then again the BlackBerry platform is such a nightmare to develop with I've been wrong about lots of things...
Maybe you should send the e-mail both in HTML and Plain-text. With plain-text, you can still format things in a decent way. There are more groups who do prefer plain-text over HTML. The e-mailprotocol, and most clients and servers support sending a message in both formats.
Ended up checking compatability of Litmus across several browsers then ensuring that text rendering was ledgible and that all my 'alt texts' were in order. (litmusapp.com) very nifty tool not cause it lets you know about any compatability problems, but allows you to refer to a link so that marketing people who believe your current Microsoft Word email template works FINE on their computer. PS it renders gmail and hotmail for free.
Only very very recently has RIM released firmware that supports HTML email. That firmware still needs to be customized by the carriers and updated by the consumers. Also, the BES server has to be upgraded to the latest version to support HTML email.
My guess is that there will not be many Blackberry users that support HTML email at this point. I have upgraded mine with a bootleg firmware and have to say that even with the support HTML emails are very hit-and-miss. Sometimes they render, sometimes they don't; sometimes it depends on the sender, sometimes it just depends on the time of day.
The HTML email support on the blackberry is pretty industry standard though, if it would render properly in the Blackberry web browser it should look fine as an email.