I generate web-page by Razor and sometimes browser show me question marks instead of one random unicode character.
For example:
I think, this question mark is displayed in place where the first byte of two-byte unicode character is in the one tcp-package and the second byte of character in the other tcp-package. But why browser does't paste them correctly?
All files encoded by utf-8. There is <meta charset="utf-8">.
Update
Question marks dependent on page content. If I change content before question mark, it may disappear or move to other place (replace other character)
Encoding the characters in UTF-8 encoding scheme is not the only thing you should consider while working with encodings. Font family also plays a great role in this thing for rendering the correct graphics for all of your characters; characters are after all just glyph drawn by graphics. Unicode takes care of all of the bytes (1, 2, 3, 4 which ever size) of your characters and shows the correct character on your screen; if your framework or font-family supports the glyph.
In your website, the font-family; probably a custom loaded, does not support this character, (or the code page to be more specific) that is why browser has to fall-back to display a question mark. You're also saying that the character is randomly chosen, so that defines the problem, for being a font-family based problem. I would advise that you try out your application in 'Segoe UI' font-family and see if that works; because that probably would work.
Apart from my suggestion, please make sure that the font-family does support that code page where this character exists. Otherwise, it will display a question mark.
Related
I have a font I want to use on my website. I live in a country where we use characters like "š,ř,č,ž,ě" and so on. I need those characters. When I open up Photoshop and use my font, it works with these (latin-extended I guess) chars without a problem.
When I use Font Squirrel to generate the #font-face, I set it all up to include almost every character possible. Still, in the character demo they provide in the download, the special-encoding characters are missing.
What could be the problem? Any solutions? I'm 100% sure the font supports the chars, but it seems Font Squirrel disregards that support. Or I'm setting something not the way I'm supposed to. Any alternatives? Thanks!
I recently bought a font and wanted to embed it into my website using web fonts.
Now the problem is: After buying it, I realized that the font is missing the umlauts, such as ä, ü and ö, so it shows an empty space instead of the (missing) character.
Is there a way to prevent this? Like tell the css to use another font for the missing characters? Or would I have to edit the font itself?
Because there is no "easy", or clean way around this except remodeling the font files, here's a small JS script to replace extended ASCII chars with a <span>. (One could only do this for the exact, required characters, but you'll propably end up asking yourself the same question again once you accidentally come across another character that's not supported.)
JS only on example text:
"Hêllo wörld. ÄÖÜßäöü".replace(/([\x80-\xff])/gi, '<span class="arial">$&</span>')
Result:
H<span class="arial">ê</span>llo w<span class="arial">ö</span>rld. <span class="arial">Ä</span><span class="arial">Ö</span><span class="arial">Ü</span><span class="arial">ß</span><span class="arial">ä</span><span class="arial">ö</span><span class="arial">ü</span>
jQuery:
$('.webfont').each(function(){
this.innerHTML = this.innerHTML.replace(/([\x80-\xff])/gi, '<span class="arial">$&</span>')
});
The nodes with .webfont should only contain text, although it should also work in most other cases.
There is no acceptable way to prevent this. Use a different font. (It is possible that there is an extended version, with higher fee, of the font you bought.) The font should be selected so that it contains all characters, at least all letters, that you may need in the text.
It is possible to use different fonts for different letters in a word, using various techniques (#font-face with range settings being the most elegant, but with limited browser support). However, it means a typographic disaster. Especially if the text contains e.g. both “ü” and “u”, there is usually a striking mismatch.
Editing the font itself is technically possible using a font editor, but normally illegal unless permitted in the font license or in exemptions to copyright in applicable legislation.
As a native Bānglā (Language: Bengali) writer, we are dependent on to Unicode Bānglā characters. As we all know Unicode is an extended version of ASCII, and all the ASCII characters are still preserved in Unicode. And the rest of the World glyphs were added then. Now in Bānglā and other languages' concern (it can be Chinese, Hebrew, Japanese or Javanese), we have glyphs on Unicode.
But in Bānglā's concern the font-size: 100% for English characters is not enough for Bānglā characters. Because of the glyphs' position inside every grid. The thing can be understood by the following image:
While English character is largely fit in a grid, the Bānglā character is shrinked to fit within because of other supporting vowel-sign-glyphs.
Hence, while we put body{font-size: 100%} it's nice for English glyphs, but with the same CSS shows the Bānglā fonts smaller.
SOLUTION, NOW
At present, how we do solution for that, is to choose a nice font that has both good English and Bānglā glyphs, i.e. "Siyam Rupali". So that, it solves the matter a very little.
NEW THOUGHT
But what I'm thinking is a bit new:
» Why not we target the Unicode glyphs and put some specific CSS for only those?
Suppose the Unicode serial number #0048 4614 5784 4578 represents the first Bānglā character and #0048 4614 5784 9999 represents the last. So, if we can do some CSS like:
Unicode[glyph="0048461457844578" - "0048461457849999"]{
font-size: 150%;
}
I know nothing like the above is present in CSS. But, is there a way we can target specific glyphs to pose different CSS styles onto 'em?
If there's a way then many of the Bānglā Unicode users will be benefited, especially a large portion of Online Bānglā Newspapers need such a tweak over content to achieve dynamic control.
This is entirely a problem of fonts. If you choose a well balanced font in which glyph sizes are adjusted in a way that mixed language text looks good together, there's no real problem. CSS can help you here in so far as you can specify custom fonts for certain characters using #font-face:
#font-face {
font-family: 'bangla';
src: url('http://example.com/mybangla.ttf');
unicode-range: U+0980-09FF;
}
This fictional "bangla" font now applies only to the Unicode range U+0980 - U+09FF, which is the Bengali block. Choose some fonts wisely and you can create a well balanced appearance in modern browsers.
Example 'BLACK STAR' ★ (U+2605)
.a:after {
content: "\2605";
position:absolute;
}
.b:after {
content: "★";
position:absolute;
}
Demo : http://jsfiddle.net/l2aelba/vBjxX/
Why someone/most recommended to use HEX like \2605 in CSS value ? Both get a same result.
It is always better to use the actual values instead of hard-coding special characters like your bottom example as there's a possibility they won't show up correctly due to the encoding of the CSS file itself.
You don't need to remember ridiculous keyboard shortcuts to add a unicode number, for one.
Remember, this hexadecimal number represents a distinct and standardised character in unicode.
Inserting the actual character leaves you at the mercy of the character-set, and indeed the font, being used to display the css.
More significantly, many icon fonts, Font Awesome being a good example, are mapped to use one of the Private Use Areas of Unicode. Font Awesome characters are within the first Private Use Area.
By it's definition in the standard, there are no standardised characters within the Private Use Areas. This means that there is no character to display, so the only tangible representation in a stylesheet is a numerical reference to it's place in unicode.
Why are these icons mapped so far out? A big reason is that some screen readers will read out any characters used in css content. This may seem wrong, but it does happen, and it needs to be defended against. Private Use Area characters will not be read out.
Personally, my approach is to use keyboard characters as they are, and use unicode numbers for everything else. Even still, if a Chinese person wants to use my code, do I know that they have easy access to all the same characters on their own keyboard? They will have numbers though.
This week we stumbled upon a rather odd bug in IE7 (surprise, surprise) when embedding a EOT font file using the #font-face construct.
To save on bandwidth, we often edit out sets of characters from a font that we know will not be used on a site. In this particular instance, we were using this font for headers that were all composed in title case, but displayed in uppercase using the text-transform property. Logically, we saved all our font files with only the uppercase characters, as we simply don’t use the lowercase.
The site rendered perfectly in every browser (including IE6 and IE8) that supported the #font-face construct, with the notable exception of IE7. IE7 only displayed the first character of each word in the proper font — the rest of the characters were displaying in the browsers default font.
Scratching our heads, we finally figured out that since the headers were actually written as title case (and therefore contained lowercase characters), even though the text-transform property was deployed and characters were appearing in uppercase, IE7 required the lowercase letters to exist in the EOT file to display the uppercase characters. (Intuitive, isn’t it?)
The simple fix was the rebuild the EOT file with both upper and lowercase glyphs, even though the lowercase characters are never used.
Problem online: http://www.testdomeinnaam.nl/mike/
How can I fix this properly? (i.e. make IE7 render the uppercase characters without having to include lowercase glyphs in the font.)
Thanks!
I think you already have the best fix - just include both uppercase and lowercase glyphs in your .eot.
Your server is using HTTP compression.
The current .eot is 22.62 KB, and it's compressed down to 13.87 KB.
Even if adding the uppercase glyphs doubles the size, it would still only be ~28 KB compressed.
Unless there's a simple "actual fix" to the problem, just stick with this.
Is it an option to transform the case on the server-side? For example, php has this: http://php.net/manual/en/function.strtoupper.php
That might fix your IE7 problem, if it's practical to use such a function.
a just had the same problem and solved it quick:
for ie7 to render the font correct with text-transform "uppercase" it's enough for ie7 that the lowercase-letters are defined in the font file, they don't need to contain real letters = they lowercase-letters in the font-file can be empty and the size of the font does not increase.