{"id":272772,"date":"2018-06-21T07:11:18","date_gmt":"2018-06-21T14:11:18","guid":{"rendered":"http:\/\/css-tricks.com\/?p=272772"},"modified":"2019-03-03T14:29:56","modified_gmt":"2019-03-03T21:29:56","slug":"using-custom-fonts-with-svg-in-an-image-tag","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/using-custom-fonts-with-svg-in-an-image-tag\/","title":{"rendered":"Using Custom Fonts With SVG in an Image Tag"},"content":{"rendered":"
When we produce a PNG image, we use an <\/p>\n Unfortunately, the same cannot be said for SVG, despite its many advantages. Although you’re spoiled for choices when using SVG in HTML, it really boils down to If you’re inlining SVG, you lose the ability to use browser cache, Gzip compression between servers and browsers, and search engine image indexing (inline SVG is not considered as an image). Even though your image may not have changed one bit, they are always reloaded and this causes slower loading times for your website, a trade-off that most are not willing to tolerate.<\/p>\n In addition, inlining SVG also causes complex dependency problems where you cannot easily insert images into HTML and have to resort to scripts (PHP or otherwise). When you have more than a few images, this becomes a huge problem when it comes to maintaining your site, because essentially you can’t use the No doubt, there are areas where inlining SVG shines — that is, if you want your images to display quickly, without waiting for other resources to load. Apart from that, clearly, you just can’t inline everything.<\/p>\n SVG is well known for its excellent quality when displayed on devices of all resolutions and its ability to refer to external resources — like CSS and fonts — while keeping the file size very small. The idea is to have many SVGs that all share a single CSS or a single font file, to reduce the amount of resources you have to download.<\/p>\n Unknown to many, sharing external resources for SVG only applies to inline SVG. Because usage of This however, is not true at all:<\/p>\n Compounding the problem is the fact that Further compounding the problem are dependency issues. For example, let\u2019s say you have 100 images, and 25 of them use a Roboto font, another 25 use Lato, 25 use Open Sans, while the rest use a combination of the three fonts. Your CSS would need to refer to all three fonts because it is quite impossible to keep track of which file is using which fonts, meaning you may be loading fonts you may not require on certain pages.<\/p>\n That leaves us with the The only problem is you will lose your fonts<\/strong>. To be more precise, if you have any text in your SVG, unless you embed fonts, your text will be displayed with system fonts, typically Times New Roman. You’ve spent hours selecting a beautiful font but the moment you use the Our first reaction is to see if we can perform font rasterization. It is a commonly used technique to convert fonts into paths, so it’ll render well on all devices and maintain zero dependencies. On the surface, this works very well, and on the editor, everything looks perfect.<\/p>\n Although the rasterized SVG came in at a whopping 137 KB<\/strong> compared to 15.7 KB<\/strong> before rasterization, we were optimistic because, after optimizing our SVG using Gzip compression, the rasterized file is reduced to 11 KB<\/strong>, slightly smaller than the equivalent PNG at 11.9 KB<\/strong>.<\/p>\n<img><\/code> tag or a CSS background, and that’s about it. It is dead simple and guaranteed to work.<\/p>\n
inline<\/code>,
<object><\/code> and
<img><\/code>, all with serious gotchas and trade-offs.<\/p>\n
Problems with inline SVG<\/h3>\n
<img><\/code> tag anymore.<\/p>\n
Problems with object tag<\/h3>\n
The myth of resource sharing<\/h4>\n
<object><\/code> tags allow access to these resources, the perception is that the browser will download a single copy of your CSS, even though you have many
<object><\/code> tags referring to the same CSS file.<\/p>\n
<object><\/code> tags are not recognized as an image, and therefore image search indexing is not possible.<\/p>\n
The image tag<\/h3>\n
<img><\/code> tag, which has a lot going for it. Because it’s the same tag used for other image formats, you get familiarity, browser caching, Gzip compression and image search. Each image is self-contained, with no dependency issues.<\/p>\n
<img><\/code> tag<\/figcaption><\/figure>\n
<img><\/code> tag to embed SVG, all that is lost. How can this be acceptable?<\/p>\n
Investigating font rasterization<\/h3>\n