I have a webpage that uses the special character ︾ in the HTML. In Firefox 4.0B12 this looks like a double downward-pointing chevron (︾). In Internet Explorer 8.0.7600.16385, however, this it just looks like ︾.
What do I need to do to get this character to display in IE the way it does in FF?
Thanks,
PaulH
Explicitly specify a font that you know contains that character (eg in a font-family CSS rule), so that you're not relying on the font fallback functionality of the browser (which varies, but Firefox is typically better at it than IE).
U+FE3E is a character intended for use as a close bracket in vertical ideographic text (Chinese, Japanese etc). You shouldn't expect it to be available on a machine that doesn't have East Asian fonts installed, and using it to get a particular shape unrelated to parentheses is really a misuse. I would not use it on the web. There are a limited number of ‘symbol’ characters that generally render reliably across the main OS default installs and this isn't one of them.
Make sure to end the character reference with a semicolon, like ︾.
You need to include the semi-colon after the HTML code: ︾.
Related
i want to design my own video player. I want to add this special character as a "volume"-button: 🔉 http://www.fileformat.info/info/unicode/char/1f509/index.htm. But it always shows a weird rectangle with the number 01F509.
Whats wrong ?
greetings
When you see a weird rectangle with the number 01F509, it means that the browser has correctly recognized the character but cannot display it due to lack of glyph for it. Either the system has no font containing a glyph for the character, or the character is unable to use such a font, due to a browser bug. For generalities, see my Guide to using special characters in HTML.
The Fileformat.info page cited has a link to a list of fonts that support the character. The list is short: Quivira, Segoe UI Emoji, Segoe UI Symbol, Symbola. (LastResort is not a real font.)
Segoe UI fonts are proprietary and available only in relatively new versions of Windows. Besides, there fonts exist in several version, and this character seems to be a rather recent addition.
This means that you wold need to use Quivira or Symbola as a web font (downloadable font). If you choose to do that, use e.g. http://www.fontsquirrel.com/ to generate the font files and the CSS code for using them. Note that both Quivira and Symbola rather large fonts, so using them just to get one glyph is a bit disproportionate.
At this point, it is rather obvious that some other approach is most probably better, e.g. using an image in sufficient size and reducing it according to font size by setting its height in em units.
To avoid encoding issues, try including the character in your HTML code using the hexadecimal entity notation: 🔉 then make sure that the font you are using contains this character, else you'll see a rectangle in place of the character.
You may create your own font with the desired character using tools such as http://icomoon.io
Also note that some browsers have issues displaying characters outside of the range 0000 to FFFF (plane 0 of the Basic Multilingual Plane (BMP)). I have experienced the issue with Safari on Windows and IE <= 8. So try avoiding this range if you want to support all browsers.
Trying to get the 1/3 and 1/8 symbols to show on IE 8-9. It shows fine on earlier versions of IE and all other browsers.
Code I'm using:
⅓
¼
IE 9 and older do not recognize the references ⅓ and ⅛ (the latter is obviously what you meant, instead of ¼, which is well supported) but instead render them literally. These references were not defined in HTML 4.01, and they were added to browsers relatively late (around 2011). Use the numeric references instead: ⅓ and ⅛ (or type the characters themselves, using a suitable editor and UTF-8 encoding).
You would still have a font problem, because the font you use for normal text may not contain these characters. In some situations, browsers are unable to use a fallback font unless you give them a helping hand with a font-family declaration. Besides, there is a risk of getting these characters in a style different from other characters, including more common vulgar fractions like ½. Thus, a careful choice of a font list is recommended; see my Guide to using special characters in HTML.
They aren't in the HTML4 spec, which is what IE9 and lower use. Only 1/4, 1/2 and 3/4 are supported.
Here is a list of what works and what doesn't.
http://stanford.library.usyd.edu.au/symbols/entities.html#Math
HTML entities are not working on chrome and IE (on windows).
I have entered the following code in my page and it works fine on mac chrome or firefox or safari, but not on windows.
<span class="font-family:Arial;">〈 〉 〉 〈 </span>
This is primarily a font issue, though there is a nasty silent change in HTML specs involved.
Modern browsers interpret 〈 and 〉 as referring to U+27E8 MATHEMATICAL LEFT ANGLE BRACKET “⟨” and U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET “⟩”, informally known as “bra” and “ket”. This interpretation is being made official in the named character references section of HTML5.
These characters are adequate for use in many mathematical notations, and the ISO 80000-2 standard explicitly specifies that they are used e.g. for certain scalar product notations. But support to them in fonts is rather limited. In old Windows systems, no font contains them. In newer Windows systems, from Windows Vista onwards, Cambria Math should be available. It is possible that you have been testing on an old Windows version, but it is also possible that Chrome is unable to find the right font. To give it a helping hand, use a CSS rule that suggests that font, e.g. with the attribute
style="font-family: Cambria Math"
You might consider adding some other fonts to the list, using fonts that are known to contain the characters. See my Guide to using special characters in HTML.
The nasty change is that in HTML 4.01, in the entities section, 〈 and 〉 are defined as referring to U+2329 LEFT-POINTING ANGLE BRACKET “〈” and U+232A RIGHT-POINTING ANGLE BRACKET “〉”. They are logically less satisfactory (and deprecated by the Unicode Standard), but they have somewhat wider font support.
So in addition to declaring fonts that contain the characters you use, you need to decide which pair of these characters you use or whether you use something else; it's a complicated question. If you use them, it is best to use them as such (in a UTF-8 encoded HTML document) or using numeric character references such as ⟨. The reason is that 〈 and 〉 should not be expected to work consistently; they probably work the HTML5 way in all modern browsers, but there is hardly any reason to take the risk, when you can unambiguously indicate the characters you want.
That particular character is simply a unicode codepoint which is an arbitrary number. There are a lot of unicode codepoints that do not have an 'official' symbol. Even if they do have a symbol, it is not necessarily the case that your font has a symbol for that codepoint. If you choose a different font, you may end up with a different symbol.
I looked at the CSS for the page and it shows this character displaying in Arial (plus a bunch of other fonts that do not matter). Windows comes with Arial so it should always pick up that font first. It looks like Arial does not have a symbol for that unicode codepoint. Anytime you do not have a glyph for a codepoint, it puts in some form of a box indicating there is no glyph
It depends on the entity, and the fonts on the system your reader is using. The issue is that these characters are not in the MathJax web fonts, so MathJax has to fall back on system fonts to find them. Some browsers are better at that than others. Your configuration controls what fonts MathJax lists for the browser to look in, so you may want to modify that to include fonts where you know your entities can be found (and you may want to think about the fact that you may have people reading your site on Windows, Mac, and Linux, and also mobile devices, so such decisions are not always easy).
Notice that when you install STIX fonts, it works for you. This is because STIXGeneral is in the default list of fonts that MathJax uses for unknown characters. You want to add others to that list (it is stored in the undefinedFamily property of the HTML-CSS and SVG sections of your configuration). Note however, that IE will stop checking fonts once it encounters a font that is installed on the system, even if it doesn't include the needed character and later fonts in the list do, so you have to be careful about the order that you use.
In my site I need to display "—", but it looks like :
( http://i.imgur.com/CiLIo.png )
in Google Chrome and Opera, but looks ok in Firefox and IE9.
Can someone supply working code of this sign ?
I can't be sure what you want to display 100%, since I am on Chrome :), but that looks like an m-dash and the correct way to display it would be to write in your code — or —. It could be thought that that character is missing from the font Chrome and/or Opera is using on your system.
Check out this link: http://tlt.its.psu.edu/suggestions/international/web/codehtml.html
To quote it:
“Smart (curly) quotes” (vs. "plain (straight) quotes") and long dashes such as em dash (—) and en dash (–) are actually considered "special characters" in HTML.
So use an m- or n-dash: — or –
The odds are that the page uses some odd font that is broken, containing “ó” in place of the em dash, and that some browsers are able to analyze the font better than others. If this were just an encoding problem (which was my first thought, too), then surely — would work.
It would be an odd font, but it’s impossible to analyze the issue further without more information. A URL would probably suffice.
Try adding this line in your document <head>:
<meta charset="utf-8">
Charset sets a character encoding that specifies to the browser / document reader what kind of characters to expect. That way, it can handle your text appropriately and in an expected manner. In this case, we're using "utf-8" as it supports a wider range of characters.
Also / otherwise, click the Wrench icon in Chrome, hover to Tools, hover to Encoding, and see which encoding is checked.
Consider an HTML page which is encoded as UTF-8, and a bizarre unicode character appears in it - form a rare language or some other Unicode idiosyncrasy.
Is there a standard behavior for such scenario? Will the browser try to find an appropriate font? Can the browser behavior be configured using HTML parameters?
The CSS 2.1 font matching algorithm means that a browser shall select, for each character, a glyph from the fonts suggested in the applicable font-family declarations and, failing that, use a browser-dependent default font. If even it does not contain the character, then “the UA [= browser] may use other means to determine a suitable font for that character. The UA should map each character for which it has no suitable font to a visible symbol chosen by the UA, preferably a ‘missing character’ glyph from one of the font faces available to the UA.”
So it is pretty well defined, but with browser dependencies. The algorithm allows a browser to display a missing character symbol even if some of the fonts in the system contains a glyph for it. Modern browsers usually don’t do that, but IE isn’t particularly modern in this respect either. Moreover, there are quirks and oddities in browsers, partly because they sometimes fail to get proper information about a font from the font itself.
You can’t configure the basic behavior, but you can play by its rules. The thing that works best is the use of author-supplied font families. If you have an odd character, you should try and determine a set of fonts that contain it and write a suitable CSS rule. However, for very rare characters the options are really: 1) the use of a downloadable font for it, 2) the use of an image. More info: http://www.cs.tut.fi/~jkorpela/html/characters.html
Yes, the browser will typically try to display it in some font as best it can. Some browsers/operating system do a better job than others. Some may simply give up if the default font for the page doesn't contain the character, but most will try to find other installed fonts that contain the character. If none matches, the browser will display some placeholder, usually a square.
And that's all. Nothing bizarre about it, that's how font rendering works.