Mysterious problem with Open Sans and ä special character. The dots of Ä are somehow displaced and I can't figure out why.
This also happens only in certain text element on certain page. The same font and Ä character works well in other parts of the same page. This also happens only with Firefox and IE.
Related
Basically I will make a font with some unicode characters. (not all) How do I apply it so that it will only apply on emojis?
Using unicode ranges will solve my problem, but will create another one. It takes the fonts for all other unicode characters away and replaces it with the default one. Is there any way to avoid this as well?
Thanks.
Edit 1
I also want to do this for input areas, so span shouldn't work..
When I put ∃ (or various other maths characters) into Sublime Text 2 it displays a question mark in a box. It might be � but it's rendered as an upright box instead of a diamond.
I copied � into sublime text and it rendered it in the same way that it rendered ∃.
All the characters in question are rendering correctly in notepad and chrome. I'm on Windows 10 if that matters.
Is there something that I can do to make these characters display properly in Sublime Text?
Update:
As roeland pointed out the issue was that the font being used didn't contain glyphs for the characters. Apparently Unicode complete fonts are uncommon. I'm using http://czyborra.com/unifont/unifont.ttf now (the only good size is 12pt).
I have this CSS:
.icon-plus-circled:before { content: '\e80f'; }
Which is displayed as a white plus inside black circle (Unicode I guess).
Need to make one more class, that would be a white minus inside black circle. But I can't find a Unicode code for that. Does anyone know?
Solved the problem. It was custom font.
There is no Unicode character for a white minus inside black circle.
There is U+2296 CIRCLED MINUS “⊖”, though it is not clear whether you want to use that or rather U+229D CIRCLED DASH “⊝”.
The notation '\e80f' means U+E80F, which is a Private Use code point. This means that the Unicode standard does not assign any character to that code point and promises to never do so. The code point is only for use by private agreements and has no meaning outside such agreements. The code you are using probably sets the font to a privately encoded special font, embedded with #font-face. While this generally works (when implemented properly) in the the sense of displaying the specific symbol, it easily causes trouble e.g. when content is copied and pasted (losing the font assignment).
Consider using images instead. Created in sufficiently large size and then scaled to font size with CSS, they do the job reasonably well.
Unicode number: U+002D HTML-code: '-';
Here is the complete table: http://unicode-table.com/fr/#002D
Unicode characters you might be interested in:
MINUS SIGN (U+2212): − −
HYPHEN-MINUS (U+002D): - -
CIRCLED MINUS (U+2296): ⊖ ⊖
CIRCLED DASH (U+229D): ⊝ ⊝
content: '\e80f' Which is displayed as a white plus inside black circle
U+E80F doesn't display as anything for me, that's a Private Use Area character that could render as anything or nothing.
There is no standard Unicode character for a filled circle with a plus or minus removed. Presumably you have some icon font where U+E80F looks like a circled plus. In that case you will have to look up the glyph set for that particular font to see if there is a matching minus.
None of the common icon fonts I know of use U+E80F for circled-plus so possibly you have a custom-made font (from Fontello or similar), in which case no-one can tell what the code point would be for a circled-minus without looking at the font file itself. Possibly the circled-minus might not have been included in it, in which case you'd have to create a new version of the icon font with it in.
Or, as Jukka mentions, switch to images (possibly SVG); icon fonts are a bit of a nasty hack.
The test is simple. A font face is applied to all the elements. for some reason, the stress characters are cropped from the top. This happens only for the uppercase characters with font lower than 300px. The problem is not visible for lowercase character.
Here is the screenshot:
The test source files are # https://dl.dropboxusercontent.com/u/33841998/font-test.rar
live example # https://dl.dropboxusercontent.com/u/33841998/test/test.html
Thank you in advance :)
This seems to be a problem with the font, a problem that manifests itself in some rendering environments. Testing with the .ttf font in Word 2007, I see the letter È (E with grave accent) as E with no hint of any diacritic mark above it; the same applies to other letters with diacritic marks. If I select the text, I can see the letters placed very high, with considerable space below baseline and practically no space above the height of capital letters. It is as if the baseline were set very high. Setting a large line height value does not help.
Contact the font vendor, or the third party that was used to produce the font files. While waiting for a fix, consider using some other font instead.
I'm making a command line version of the board game Blokus and I'd like to have the pieces take up the full height of a line. I tried to use the Unicode character █ (U+2588) but it leaves vertical gaps in the lines like so:
Does anyone know how I can have it take up the full line?
Those characters are, by definition, supposed to fill the entire character cell. If they aren't, there may be an issue with the font you're using. (For instance, your default font may not have that character, so the terminal is having to use a substitute font with different metrics.)
You may be able to work around this by "faking" a block character by entering inverse video mode ("\x1b[7m") and outputting a space character, then switching back ("\x1b[0m") when you're done.
The U+2588 should take full height of a line in a terminal, but due to font issues, it does not always do that.
The Block Elements characters are described in clause 15.8 Geometrical symbols in the Unicode character: “the legacy block elements are designed to fill some defined fraction of each display cell or to fill each display cell with some defined degree of shading. […] When emulating terminal applications, fonts that implement the block element characters should be designed so that adjacent
glyphs for characters such as U+2588 full block create solid patterns with no gaps between them.”
However, fonts that support U+2588 do not always implement it correctly. So you should check whether you can set the font to one that has a correct glyph for U+2588, such as DejaVu Sans.
If you are using U+2588 and friends in an environment that is more complicated than a simple terminal, such as software emulating a simple terminal, or in a word processor, you probably have another issue, too. Even though U+2588, when implemented correctly in a font, takes the full height of the font, it does not usually take the full height of the line. Normally line height is larger than font height (font size), and you would need to take extra measures to make them the same (to make the text “set solid”).