I’m trying to keep HTTP requests at a minimum in the website I’m developing. FontSquirrel and Transfonter have been plenty useful to encode WOFF2 into base64, but I’ve had no luck with variable fonts and keeping all their features/axis (they result in static fonts).
Is there a way I can encode WOFF2 variable fonts into base64 and keep all their customizable goodness?
Related
My goal was to design a simple website, with a custom font (that isn't available on Google Fonts). I used FontSquirrel's generator for webfonts as a supplement to manually-linked fonts. What was expected was for the src for the WOFF and WOFF2 files to be just simple links to the files. What happened was the generator added this garbage data (which was taken on pastebin as spam and would probably be taken as spam here as well) for every WOFF and WOFF2 file. This threw me off.
As I already stated, I manually linked the files and it did not work, however this may be just a side effect of me not knowing how webfonts work. I tried to look up about this on the internet and found irrelevant results.
I used FontSquirrel to generate the files, and these are the settings I used. The extra font filetypes are for debugging this problem (it only happens to WOFF as I found out).
Am I truly not linking WOFF files properly? Is WOFF supposed to be linked like this? Is the generator supposed to insert garbage data into the WOFF srcs?
edit 1: I only figured out now (after someone pointed it out) that this "garbage data" may just be simply raw font data. I still don't know, however, why this happens, if this is a bug and I can just use the simple src attribute pointing to the file, or is this intentional?
When downloading the css resource for a Google webfont, the result seems to be dependent on the browser.
When I open this URL with my browser (Firefox or Chrome):
https://fonts.googleapis.com/css?family=Roboto
I get this result which contains several woff2 font sources for different unicode character ranges.
When downloading the same CSS resouce URL with CURL for example, I get this result containing just one .ttf font, which appears to contain only a default unicode character range.
So apparently Google looks at the agent string from the HTTP request and then adjusts the result accordingly.
Is there a way to get a .ttf with the full unicode character range, i.e. everything that is also included with the "multi woff2" version? Most importantly the Latin and Latin-Extended characters.
I can convert woff2 fonts to ttf. However I don't know how to combine or merge multiple woff2 fonts into one ttf, or into one woff2 and then convert that.
Or am I doing something wrong and should I use a different approach altogether?
If you pick the font on the Google Fonts site, it'll show a dialog with the CSS code to use as webfont. Google will indeed send a specific version to your visitor's browser, depending on what it supports.
If you want the "full" fonts, grab the desktop version as .ttf file by clicking the download button. It'll have all the OpenType features and un-subsetted character set support.
I have a css font family like below(I have shorten it because of displaying limit otherwise it is much much bigger than what I have present here)
now can you please let me know that if there is a way to convert the url()content inti .ttf font formats or other standard font formatS ?
#font-face{font-family:'web_font';
src:url('data:font/opentype;base64,d09GRk9UVE8AAHUkAA0AAAAAvnQAAhOIAAAAAAAAAAAAAAAAAAAAAAAAAABDRkYgAAABMAAAXwMAAIcHbRkIAEZGVE0AAGA0AAAAGgAAABxoptAkR0RFRgAAYFAAAACWAAAA3hpVGOlHUE9TAABg6AAABf8AABkwdgAPiEdTVUIAAGboAAAGngAADSIYX0AXT1MvMgAAbYgAAABXAAAAYI8WBFNjbWFwAABt4AAAAZYAAAKquYd/vWhlYWQAAG94AAAAMwAAADYIcsC0aGhlYQAAb6wAAAAhAAAAJAuVB6xobXR4AABv0AAAA0cAAAaQAUI5cG1heHAAAHMYAAAABgAAAAYBpFAAbmFtZQAAcyAAAAHuAAAFH7QO6sRwb3N0AAB1EAAAABMAAAAg/h4AHnictLoHXFRH1zjMvbC7V9S1cRcFXVDBggTpxRbFrigWpCq997pUkY4w9N5BepMuoGI3WGNsURMTY0wsURITU2Zx8Hm+uQsui/F58/zf9/eBF2fOOXPanDnnzN0lpGRkpAiCmBLq4mjl4uXga+HiKEWQUoTUGuF0qeHTxPAZcvgpQ+');}
1) First of all you need to save the base64 string as a file.
Some of the online service is restricted to how much you can enter, so simple do this locally by just opening the base64 string in your browser and you will be promoted with save as dialog, choose any name you want
Alternative (if the browser don't allow you to enter such a long url) create a download link open the page in any supported browser that supports download attribute (chrome, firefox, opera)
download web_font
2) Then you need to figure out what file extension it's
With just the small amount of base64 string you provided me i was able to recognize it as a woff file, by looking at it with a hex/text editor. I uploaded the saved file to https://hexed.it and could read in the beginning that it said woff
So now you have your web_font.woff file!
3) Convert it to TTF with the right tool for the woff - format
I can google that for you and found for example fontforge that dose this and some free online service as well.
onlinefontconverter.com makes a good job at converting unknown formats by looking at the magic number instead of the file extension so you can have your ttf file directly. And you don't have to install any program either. But it doesn't tell you what the original file extension is.
Don't do this? If you have an actual font file, like a .ttf file, just use that in your CSS.
#font-face {
font-family: WhateverNameYouNeed;
src: url('location/to/your/file.ttf') format('truetype')
}
aaaaaand we're done. For universal acceptance, wrap it as a WOFF and then use that instead of the ttf OpenType font file, so that every modern browser supports it.
NOTE: you can't just blatantly convert your fonts, though. If you do not own the rights to the font, or the font does not come with a license that says derivatives are allowed, you are not allowed to convert this font.
Web fonts are delivered in various formats to take care of different browser requirements, the main formats that I am aware of are:
ttf
otf
eot
woff
svg
I also know that not all of these formats are supported by all major browser vendors. However, it would also seem that fontforge (and probably many other utilities) are capable of converting between these formats easily. It is my understanding that "woff" appears to be the "new" standard for web fonts.
My question is this:
Are any of the formats "lossy" in the sense that if I started with a WOFF file, converted to OTF, and then back to WOFF, would I end up with a file that didn't have all the metadata? Or are the formats essentially so similar that any of them is as good as another as a starting point to get a font in all the formats?
woff is a simple wrapper around ttf or otf + metadata (and optionally private data). EOT is a simple wrapper around ttf (technically it is possible to create a otf-in-EOT, but this is probably not widely supported); virtually all of the information in the EOT wrapper is derived from the contents. So conversions in any direction among:
TTF <-> EOT <-> TTF-in-woff or
OTF <-> OTF-in-woff
should, or at least, can be lossless (not counting metadata). I say can, because it will depend a great deal upon the tool used to convert and to some extent upon the operator of the tool and what you do with the metadata.
To answer the specific question, "if I started with a woff file, converted to OTF, and then back to woff, would I end up with a file that didn't have all the metadata?" is a little tricky. If the original woff was wrapping OTF (not TTF), then the answer is yes. But if the woff was wrapping a TTF, the answer would be no, because there needs to be a conversion from TTF to OTF, and that conversion is lossy.
Likewise for woff -> TTF -> woff; if the starting woff was wrapping a TTF, this would be lossless (except for the metadata), whereas if the original woff was wrapping an OTF, it would be lossy (because there's a conversion from OTF -> TTF in that process, and that conversion is lossy).
Is it possible to embed web fonts in a standalone HTML page using a dataURL or something similar, without having to load them from an external file or address?
that's when you encode the font in base64. you will technically have a "gibberish string" representing that font. this will increase load times since base64 is very long.
there are tools online that do that for you. essentially, it takes the font file, encodes it in base64 and replaces the font location with the base64 encoded version.