I'm trying to use the MusiSync font to embed a sharp and flat symbol in a line of text. In order to keep these symbols from being tiny I have to make their point size twice the size of the rest of the text. Unfortunately, this messes up the line height in Internet Explorer and I cannot find a way to control it. You can download the MusiSync font at:
http://www.icogitate.com/~ergosum/fonts/musicfonts.htm
My attempt to use this font in a web page can be found at:
http://www.williamsportwebdeveloper.com/MusiSync.htm
I opened up Photoshop and used the font you link to. There is a huge amount of white-space above each glyph in the font itself. The font is poorly designed.
If you set your style to this, you'll see the issue:
.style2 {
font-family: MusiSync;
font-size: 24pt;
border:1px solid #000000;
}
The problem appears in FireFiox 3 as well, its just manifesting itself a little differently.
You may be able to hack your way around this somehow, but it's going to be ugly. Unless you're using a lot of different font sizes, you may be better of using images.
Seeing that you are trying to use a very uncommon font, why not implement sIFR?
It will (possibly) solve some of your line height issues as well.
Read up here.
sIFR is an excellent choice for non-standard fonts.
You embed the font in a flash movie (don't worry most of the work is done for you) and add a bit of code to your page and the sIFR javascript will replace classes/id/tags etc with a flash movie containing the text/font that you're aiming for:
From http://www.mikeindustries.com/blog/sifr/
A normal (X)HTML page is loaded into the browser.
A javascript function is run which first checks that Flash is installed and then looks for whatever tags, ids, or classes you designate.
If Flash isn’t installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you’ve designated as something you’d like “sIFRed”.
Once measured, the script creates Flash movies of the same dimensions and overlays them on top of the original elements, pumping the original browser text in as a Flash variable.
Actionscript inside of each Flash file then draws that text in your chosen typeface at a 6 point size and scales it up until it fits snugly inside the Flash movie.
An excellent cross browser platform indepent solution for non-standard fonts.
Related
I have an – character that becomes invisible when the text is rendered at a smaller font size (the applicable font-size rule is 14px, at which it is invisible; if I zoom in one level in Firefox, it becomes visible.) I have only seen this behavior on Firefox on Windows. With Firefox on Linux, I see the character at all sizes. I believe that what happens is that at smaller sizes, the dash is allowed to render as a line of zero width. So the question is, how can I remedy this? Here's what I can think of -
Try a different dash character and hope for the best
wrap the dash in a span and force it to be bigger - seems clunky
maybe my font definition is broken - this is embedded Open Sans
any other approach I'm overlooking?
Don't use any of the legacy 90's Microsoft core fonts in Windows (Arial, Verdana, etc). They have very aggressive hints intended to prevent "fat" or "blurry" stems at all costs, that result in some of those stems disappearing at small sizes. Perpetuating the pixelated look Windows users were accustomed to was the only thing Microsoft cared about at the time (there are built-in workarounds in the Microsoft rendering stack to hide the bugs of those fonts, but they don't exist in third-party apps).
Have you tried a different font-family to see if it's showing the same problem?
This is a problem of fonts, not browser support. Try to use another font like "Times New Roman" to verify.
In the case of the small icons, the most reliable solution is to use the CSS #font-face rule to ask the browser to download a particular font. Then you'll know for sure that the user has an appropriate font installed. There are even some fonts designed specifically for this use, with extra icons built in: "Font Awesome" is a well-known example.
Please look here for more information: Does every browser support all unicode?
For my current workflow I use iconic web fonts generated with the Icomoon. It’s a very easy and fun technique with an obvious advantages:
Icon behaves just like any other glyph, so any text CSS transformations can be applied to it in a natural way, like text-shadow, text-decoration, color etc.
Easy reuse, just add necessary font-family to element.
But it has major flaws do not let me sleep.
Font icons are blurry no matter how perfectly its curves are aligned to a pixel grid. Not to mention awful Windows rendering.
It’s hard to add new icons to the font, especially when vector source font is made from is not available and even lost.
It requires bunch of different font versions (woff, eot, ttf) for acceptable cross-browser support.
In the end fonts are not really for graphics at all (especially not monochrome), it seems to not the right way to use dummy empty and non-semantic <span class="icon"></span> for this purpose.
Well, the obvious alternative is SVG, which has no mentioned disadvantages. But has it’s own flaws, which do not let me use it’s easily.
A lot of small files are quite simply not acceptable in our HTTP/1.1 era.
Creating of icon modification is not an easy task and requires manual editing, which is also rather strange for our just-type-npm-install era.
I've googled for some npm packages which hasn’t satisfied me for some reasons.
So, I’m asking your advice how to manage this trivial and routine task. Is there productive and reliable way to generate SVG sprites with modified variations of original icon and bitmap fallback for old browser?
It doesn't make sense to talk about "supporting old browsers" without:
knowing what the majority of your users will be on (which'll be multiple browsers of course), and,
what support for the feature you want to use is for those browsers, for which we can use the handy http://caniuse.com
With that said, this is not going to be an answer so much as an explanation of how all those points you present "against" fonts are unfounded. Answers are great, but in this case we need to set the record straight so you can make real decisions based on facts, instead of (either "never", or "no longer" valid) preconceptions. I spent way too many years of my life working with fonts from an engineering perspective to let you maintain these claims =)
"Font icons are blurry no matter how perfectly its curves are aligned to a pixel grid. Not to mention awful Windows rendering."
This is plain old not true. As vector graphics, if they render poorly, SVG will also render poorly at the same size, although SVG will typically render worse: fonts actually allow for micro-outline-optimizations for dealing with small point sizes (.otf is better at this than .ttf, but the font maker needs to have spent the time to put them in. Pretty much all professional fonts come with that work done), and SVG doesn't, because it has no instructions in its vector graphics language to do so. As such, fonts render either on par with (if they have no optimization instructions), or better than (if they do) SVG.
For example, Font-Awesome comes with outline optimization that allows it to render pixel-perfect all the way down to a font size of 14px, which is already smaller than what browsers use as default size for text on a page (virtually all browsers agree to use a default of 16px serif). If you took its icon set and converted it to SVG, then tried to use those scaled down to match a 14px size, they would look an absolute blurry mess.
Or you can use an icon set that goes further, such as Symbol Set which has explicitly been designed for grid alignment, which means that even at sizes lower than intended, it still renders remarkably crisply.
SVG loses here.
As for Windows rendering, it might look bad, but that's not Windows's fault. Both Uniscribe and DirectWrite are really good at rendering fonts. Like, really good (which may not be a surprise, since Desktop Publishing has traditionally been Microsoft's core business since pretty much its beginnings, although that's shifting). Browsers that hook into them render fonts really well: IE has even supported web fonts since IE4... That's 1997. That's before HTML4 was even a thing, we were still on HTML3.2 at the time.
The problem isn't so much "Windows", as it's "older browser that are not IE, on Windows". Browsers didn't really care about web fonts for a very long time. It's only the last few years that major effort has suddenly gone into making sure they come with good Font shaping engines (like Harfbuzz, which is now used by Firefox and Chrome), and you won't get nice results for Fonts unless you're using a modern version of "not-IE" on a Windows machine.
And then finally a problem specific for "font vs SVG" on Windows and IE: While IE has supported web fonts since pretty much forever, SVG support only landed in IE9, so if you need to support IE8, you can't even use SVG. In the case for this very specific target audience, "fonts vs. SVG" isn't even a question, you have to go with a font.
"It’s hard to add new icons to the font, especially when vector source font is made from is not available and even lost."
No it isn't, you're still using HTML with CSS, so do what we always do when we need "letters not in this font": use font-fallback: font-family: iconfont1, iconfont2, iconetc.
"It requires bunch of different font versions (woff, eot, ttf) for acceptable cross-browser support."
Not for a few years now. These days we do not need multiple sources: caniuse shows us that everything supports WOFF and has done so for a few versions.
Even IE, although if you need to support IE8 you'll have to also find yourself an .eot (which is literally just a ttf file with an extra bit of metadata so IE will accept it... just like WOFF!) and then live with the fact that if this requires a conversion from otf to eot, you're going to end up with a shitty font because it's a lossy conversion (like converting .png to jpg. Excellent conversion software can generate a decent result, normal software will generate a mediocre result).
And because everything supports WOFF, we (thankfully) don't need ridiculous all-encompassing sets of ttf+otf+eot+woff+svg anymore, with a "bulletproof" #font-face rule that tries to optimize load order so not too many files are needlessly loaded - just use WOFF. Done. And in a pickle, add .eot as first source (with format indicator) and everything except IE will skip over it.
It's also worth looking at SVG font support: virtually nothing supports it, and those that do are in the process of deprecating it. SVG fonts as a thing has been discontinued because the results of using SVG fonts turned out to be incredibly much worse than using real fonts, underlining the explanation on point 1.
"In the end fonts are not really for graphics at all (especially not
monochrome), it seems to not the right way to use dummy empty and
non-semantic <span class="icon"></span> for this purpose."
Both of these claims are incorrect.
Fonts are for encoding vector graphics that are to be used in typesetting context. That can mean letters, or icons, or emoji; it can even be musical notes or mahjong tiles. And the way they do this has until very recently been as "single color", which is literally what monochrome is. The only place where monochrome rendering for fonts might be a problem is on monochrome monitors in which case: where the hell are your webpages being accessed that they can render webfonts, but do so on ancient-even-for-CRT technology O_O
As for semantics: if you need an icon that has no meaning inside the document and is purely UI candy then you do want a non-semantic element, so that text readers and the like for people with visual or reading disabilities don't get your icon read out loud to them, and text indexers for search engines (private or public) can safely ignore them entirely. Your icon should definitely be a non-semantic empty element that can be skipped by everything.
With all that said, what about bitmaps?
Bitmaps absolutely win at low point sizes, but—and this may be a surprise—fonts can actually contain embedded bitmaps so that they can render actual bitmaps, not vector graphics, at small point sizes.
Of course, only high grade fonts come with those, but that's also a thing you check for: does the icon font you're looking at come with bitmaps? If so, we have a winner. If not, then you might want to take the icon font you want to use, generate your icons as a bitmap file, and then manually clean up the bitmap before using it on your site.
This process is inherently manual, no utiltiy will do this for you and not get it wrong enough times that you still need to manually fix things up, but if you do go down this route, and you make your own icons based on a well known font, at a point size that makes the icons look better than the font rendering: give back to the world and send those bitmaps back to the font creators so that they can use them to build out the font's EBLC, EBDT, and EBSC tables and everyone else gets to enjoy having the bitmaps live inside the font, so we don't need to do crazy CSS sprite rendering.
I'm searching for a method to tell the browser to render each glyph rendered with a specific font, e.g. FreeMono, in a bigger font size than glyphs rendered with other fonts. The reason for that is, that I use characters like ᚠ in a website and these glyphs are rendered using FreeMono in Chrome (see inspect element → computed → rendered fonts) and they look always like they're to small to fit the surrounding text. Is there any way I can do that?
You cannot. CSS has no tools for such font-specific tuning, apart from the font-size-adjust property, which has very limited effect, limited browser support, and buggy support.
If you use a character such as “ᚠ” U+16A0 RUNIC LETTER FEHU FEOH FE F on a web page, then it will be up to each browser in each system which font (if any) is used to render it, at least if you do not explicitly suggest some font(s) that contain it. It may be FreeMono, but most computers in the world do not have it. Besides, in FreeMono, “ᚠ” is rather large—taller than uppercase Latin letters. So if it looks too small, the reason might be a mix of fonts.
To make, say, Runic letters match the style of other text, you should try and find a font that is suitable for both—so that you can use a single font, designer by a typographer to make things fit. You would then probably need to find a suitable free font and use it as a downloadable font (with #font-face). It might be FreeSerif or FreeSans; only in very peculiar circumstances would I consider FreeMono, a monospace font, suitable for rendering computer code in some cases and mostly unsuitable for everything else.
So, I know that this isn't something that is normally a good idea for a website, but I have a special purpose/intent for such a use:
I have a multilingual dictionary that I'm working with online, where I need one of the languages to be in a specific font, from a file that I specify locally. However, I want this language to be rendered ONLY in this font, as if it is rendered using any other font, it will render incorrectly. That's all fine and dandy, and I can load the file in CSS and whatnot.
But I want to make it so that if it can't load that file, either for one reason or another, or something goes wrong, it can't go to another font. Basically, render this text using this font, and if you can't do that, don't just try and render it with Arial or whatever is the default -- show me blocks, show me a stark something.
I've spent a bit looking around, but am not sure what in CSS I would be using for this. Suggestions/help? Thanks :)
As an update to this question, since April 2013 there exists the Adobe Blank Font, which can be used for that purpose.
You may build a cross-browser css with FontQuirrel WebfontGenerator and the Adobe Blank font files.
If you just need the font in OpenType format you can use this single css file with the already embedded font
You can't do this. Text is text and text has to have a font that it is to be rendered in. If you really want, there's probably some weird JavaScript function that can detect the actual font being used for the text and if it doesn't match the one you want, then you can hide it or something. But in the end, your only option is to have the text displayed in some obscure font, or completely hide the text. If the text is visible, it has to be rendered using some font.
You could also theoretically create your own font where all the characters are just blank, but that seems highly illogical and such a waste of resources to make people download a font just so it can display meaningless emptiness.
There is no "don't render fonts" option. It's a font, it needs to be rendered, or else it's hidden visually in the DOM.
You could use Javascript to find out the font being applied to a certain block, and if it's not the font you want, just hide it. Or display a message.
Another solution is somehow specify the content to be empty. For example, I'm trying to override the +/- character that a Webix tree displays using Font Awesome:
#lhn-tree-container .webix_tree_open:before {
content: '';
}
This only works with the :before and :after pseudo-elements though.
I wanna create special font containing only icons. and for each letter will be diffirent icon.
I want to embed this font in css.
and use like this
if i need some icon:
<a class="icon">f</a>
and css
<link href='http://fonts.mysite.com/css?family=MyFontWithIcons' rel='stylesheet' type='text/css'>
which contains:
#media screen {
#font-face {
font-family: 'MyFontWithIcons';
font-style: normal;
font-weight: normal;
src: local('MyFontWithIcons'), url('http://fonts.mysite.com/font?MyFontWithIcons') format('truetype');
}
}
and to show icons with icon class:
.icon {font-family: 'MyFontWithIcons'; }
And letter "f" will be replaced with icon inside font which located on the place of f letter.
and css works with font and replacing f with icon inside font.
I think it's good idea or not? font file is less in size than lots of image icons.
and also with this technique I can use diffirent font colors = diffirent icon colors? sizes and so on.
So, it's good idea or not?
The problem with using a custom font for icons is that you've got no backup plan if:
Your user's browser is too old to support #font-face
The user agent isn't your traditional browser (eg. Screen readers for the blind, search engines, HTML-to-text converters, etc.)
The user copy-pastes the text containing the "icon" into something that discards rich formatting information or doesn't have the font in question.
The user agent will never support #font-face (Eg. Textual web browsers like Lynx, Links2, and ELinks for Unix/Linux)
The user is behind a corporate proxy that discards or mangles headers that your browser demands before displaying custom fonts. (more common than you think)
The user is running NoScript with the default font-blocking behaviour enabled to protect against 0-day exploits in the font engine.
Images provide the alt attribute for just this reason.
However, if you're going to use a font for icons, make sure you store your glyphs in a Unicode Private Use Area. That'll mitigate the problem a bit by ensuring there's probably no conflict (Companies can and do sometimes use PUA glyphs to store custom data) and, if they're coded smartly, screen readers could know to gracefully ignore PUA glyphs.
As for implementing a fallback, I'd suggest using Modernizr (specifically, Modernizr.fontface) to test for support.
It's a good idea but it doesn't work in all browsers (yet). Also, it only works with 2 color images (black and transparent), which makes it rather limited. For people with text browsers or text to speech software, it won't make any sense. It's not really 'semantic', because the <img>-tag was meant for images. Using fonts for that won't make any sense from a html-only perspective. It also clutters your css.
So that's a lot of bad things just for a little bit less bandwith; I wouldn't bother.
#font-face is not supported uniformly across browsers. Its a bit of a task to cater to all browsers esp. if including IE6
Accessibility: screen readers won't read icons, they would still see an 'f' and not an icon
You would need some fallback to degrade gracefully
All the other answers focus on the downsides.
I am, personally, a big fan of using icon fonts.
Here are some good reasons to use an icon font:
You can seamlessly use icons inline with text. If you include an icon inside of a block of text, it will inherit the font size and color of its parent, and will be aligned with the accompanying text's baseline.
you can change the color of icon dynamically using css, without having to create and upload additional image files and use js to manipulated the markup. this means that a) you are keeping style determinations where they belong, i.e. in your stylesheets and b) you can simply and easily make your icon colors contextual (e.g. all icons inside headers are white, or else they are black) and themable (e.g. all icons are white if body has class dark-theme, and all icons are pink if body has class tropical-theme)
the icon can easily be scaled without using additional bandwidth (as it would if you were increasing the size of the image file), without having to create and upload additional image files. corollary: you don't have to worry about different screen resolutions and don't need to make any allowances for retina, etc.
your font file will likely have a smaller file size than your image files would so, again, save on bandwidth.
if you use a font generator such as fontello, your collection of icons will automatically be catalogued for you and your designers to scrutinize, in a demo file. in addition, fontello has an API so your font generation can be managed automatically as part of your build process.