I have a huge problem. I just updated my websites homepage to display a unicode hexagon character: ⬢ ⬢ aka U+2B22
I made it 200px big and filled it with text. It looks good and works fine on my computer. With both Internet Explorer (win8) and Firefox 28.
I tested it on 5 different computers and it didn't work there! Tested with Firefox 28 and Internet Explorer (win7) on each device and on one computer even with the newest Chrome.
So what am I doing wrong? How is it possible that it works on my FF 28 and on 5 different devices with FF 28 it doesn't?
I already tried:
<?php header('Content-Type: text/html; charset=utf-8'); ?>
and in HTML directly:
meta http-equiv="content-type" content="text/html; charset=utf-8"
Is U+2B22 not part of utf-8?
Try it yourself here, scroll to the very bottom of: http://jtauber.github.io/articles/css-hexagon.html
For my PC it looks like this: http://250kb.de/u/140401/j/RzN1lYTL8fLJ.jpg
On other devices it looks like this: http://250kb.de/u/140401/p/VEeerGhyv4lM.png
I appreciate any help!
The character U+2B22 BLACK HEXAGON is included in a few fonts only. None of those font comes with Windows or with other widely used software, so in most computers, there is no font containing it. Moreover, browsers may fail to render the character even if some font in the system has it. For some more general explanations, see my Guide to using special characters in HTML.
In this case, the font setting is font-family: "Helvetica Neue", Arial, Helvetica. None of those fonts contains the character, so each browser tries to use other fonts in the system, in a browser-dependent order. In your own computer, you have a font that contains the character. You may have downloaded and installed it, or it may have come along with some software
What you could do is, alternatively,
a) specify, in a font-family declaration, a list of fonts known to contain the character. This could help against problems of browsers not finding a font, but this would not matter much.
b) use a downloadable font (web font, via #font-face). This would mostly be overkill if you just want one character for essentially non-text use. Fonts that contain U+2B22 are generally large.
c) use an image instead, possibly as a background image. This would be here the rational choice, especially since you would not use U+2B22 as a character in text but as a background of a kind.
Regarding the question “Is U+2B22 not part of utf-8?”, characters aren’t really part of utf-8. Instead, utf-8 is a transfer encoding for characters, and all Unicode characters (and, moreover, all Unicode code points) have representations in utf−8. Besides, the page mentioned does not contain U+2B22 as such but as the character reference ⬢, and this works independently of character encodings. Thus, this is not an encoding problem, but a font issue.
These computers on which it does not work do not have a font installed which contains a glyph for this particular character. That is all.
Solutions would include to not depend on users having fonts with such unusual characters installed and provide them as web font instead (which you might have to create) or to use an image, SVG or canvas instead.
Related
I have a problem with accented letter from Google fonts. Letter "š" shows correctly in all browsers on my PC but it's replaced with system font in all mobile browsers, Android and iOS (it works fine in Android Chrome, though). Font is Abril Fatface and you can see result here Screenshot
And here https://jsfiddle.net/Lauven/zkL04kbx/embedded/result/
It acts the same on my server and on Jsfiddle.
So far I've tried these things:
Put <meta http-equiv="Content-type" content="text/html; charset=UTF-8"> and <meta charset="UTF-8"> in head section
Added utf-8 encoding to .htaccess file
Saved file with utf-8 encoding in my text editor
But I'm not sure it's the problem with encoding anymore since letter displays correctly in browsers on my PC and Android Chrome. Anybody have any idea how to solve this?
Update: It actually works only in Chrome/Windows and Chrome/Android
I had the exactly same problem, with letters correctly being rendered in Chrome but being replaced in Firefox.
The solution in my case was that I have forgotten to include Latin extended option when downloading the font from Google Fonts.
In your case when downloading the font from https://www.google.com/fonts#UsePlace:use/Collection:Abril+Fatface in the section 2. Choose the character sets you want: make sure you have included Latin Extended (latin-ext) option.
That font does not support the character(s) you're trying to use with it. Have a look at http://jsbin.com/zucatufaxi/edit?html,css,output: the final š is styled nothing like the rest of the text.
So the real solution here is going to be "make sure the font you're using supports the text you need to style", or see if it supports combining characters and use the unicode sequence s + combining caron: š.
Although a quck test in the above bin shows that this sequence is not properly supported by the font, so: you'll either need to find a font with full support, or find a font that looks similar enough as fallthrough font (the first usually makes more sense).
UPDATE: I tried to use the same font hosted on my server instead of using Google fonts and since then everything works fine across all browsers. I still have no idea what was the problem with Google fonts though. But at least it works this way.
I have a webfont that doesn't support Cyrillic. The font only has latin chars. If I try and display some Cyrillic chars, instead of displaying blank or corrupt chars (as I would expect it) it bypasses the webfont and displays them in a system font instead. Whilst this is a good thing I don't know why or how. As I understand it, if a font specified in the CSS isn't supported by a browser or the browser doesn't support webfonts it is then that a substitute font is put in place. However this is happening if the characters used aren't supported. Is my understanding of this correct?
it can be difficult when using a font that is not supported in your language.
It varies from font to font and browser to browser.
So there is no hard and fast rule sorry.
I would recommend making sure you HTML is set to support Unicode fonts.
<meta charset="utf-8">
I would also programme your font so it is in a stack,(has a default to full back on if unsupported)
And give it and test in all browsers to see if it defaults or doesn't show.
You may wish to find a font that is suited to that language.
Most browsers do missing character fallback by default, so you never see blank characters when something's missing. If the developer uses a font family stack like font-family: MyCyrillicFont, Arial, sans-serif your browser will use the next available font. Otherwise, the browser itself has a default font setting (that the user can typically choose).
In short, browsers have fallbacks on the characters level.
My site has thumbs up images that I want to render these as HTML entities. The decimal and hex codes are:
👍
👍
respectively.
In FF, both codes are rendered as a thumbs up but in Chrome neither is (nothing is displayed at all).
Here is the rendering (in white) on a dark background.
Why is this happening?
In general, for emoji entities like this, you can't rely on the end user's font including it. This is especially true of Chrome (as of December 2014), which is the last major remaining browser where rendering emoji doesn't work by default.
You're best off using an image here.
A custom font is also a good solution (hat tip to #Vucko).
The font support to THUMBS UP SIGN (U+1F44D) is very limited, as usual for any characters added to Unicode recently (during the last few years). A large number of users’ system have none of the fonts, so the only way to make almost all browsers render the character is to use a downloadable font (web font) via #font-face; in practice, you would use Quivira or Symbola for this. As they are rather large fonts, using an image may be a better option.
What happens when you use the character and do not specify the font at all, or specify a font or list of fonts not containing that character, is that browsers will use some backup fonts. They may do this in different ways, so that browsers in the same system render it differently, since they scan thru the list of fonts in a different order. Moreover, browsers have bugs in this respect. They are expected (according to CSS specifications) to render the character if any of the fonts in the system contains it, but they often fail to do that. Sometimes this is caused by a faulty font: a font contains information according to which it has a certain character, so the browser uses that font, but in fact the character is missing and some generic symbol appears. Sometimes we just don’t know why it fails.
You can avoid such bugs by explicitly listing fonts that are known to contain the character. But this is of course ineffective when the user’s system has none of the fonts.
<style>
.emoji {
font-family: Segoe UI Emoji, Segoe UI Symbol, Quivira, Symbola;
}
</style>
<span class=emoji>👍</span>
I am working on a website with multilingual characters (Latin,Cyrillic,Japanese, Chinese and so on) mixed together.
I've used the following meta-tag to ensure the correct visualization of the content:
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
My question is: is this sufficient to be 100% sure that all the users will visualize the content without any problem? Do their OS need to have specific support for such characters?
Silly example: do all the modern browsers and/or OS support the Korean Alphabet/characters or are the users required to install them?
The meta tag does not guarantee anything. It declares that the encoding is UTF-8. It may be overridden by HTTP headers. See Character encodings by the W3C.
If the encoding has been declared as UTF-8, and it it actually is UTF-8, then you can be pretty safe that are all browsers get the characters right. Whether they display them depends partly on availability of fonts, partly on font-family settings in CSS; see my Guide to using special characters in HTML. It does not depend on the OS.
Regarding Korean (Hangul) characters, the Fileformat.info data on font support seems to be too limited (I have reported this to the author). In addition to fonts listed there, at least the following fonts contain them, or at least a large part of them: Batang, BatangChe, Dotum, DotumChe, Gulim, GulimChe, Gungsuh, GugsuhChe, Malgun Gothic, Sun-ExtA.
So you could write a long list of fonts (in order of preference) containing Korean characters, as the font-family value. I would expect this to work in most modern computers, but not all. To maximize the odds, you would need to use a downloadable font (web font) via #font-face, such as Sun-ExtA, which appears to be a free font, available from Alan Wood’s repository. Beware that it is a large font, and you would need it in a few formats, generated e.g. with FontSquirrel, to cover different browsers. Like most large fonts, it has one (regular) typeface only, so you should not try to use it as bold or italic; make sure you override and bold and italic settings that browsers tend to have for many HTML elements, like heading elements.
is it just me, or does Chrome no longer render HTML characters such as the —? I've tried changing the DOCTYPE, changing the character encoding meta tag, changing the character encoding option in Chrome, and even using the entity number instead of the entity name. I cannot for the life of me get Chrome to display an em dash, and I've noticed that it isn't rendering it for other sites as well. Has anyone else had this problem also?
UPDATE
Are you sure the font you're using
actually has an em dash character? - Andrew Marshall
It just dawned on me what's going on. A while ago, I wanted to be able to use Helvetica Neue on Windows, and I didn't want to fork out a few hundred bucks, so I copied the font file from a Mac, converted it to a TTF on Ubuntu, and brought it over to Windows. I guess the tool I used didn't convert all the characters because it obviously can't display the em dash. The only reason I noticed the problem in Chrome is because the other non-webkit browsers wouldn't use Helvetica Neue for some reason.
Arg... I feel stupid. Thanks for the help!
I'd argue that HTML entities should be avoided (except &, of course). Instead just use the actual character and declare (and save) your HTML as UTF-8, something you should already be doing.
There are several top sites that do this, in particular with the use of © instead of ©.