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.
Related
I made a font. Some characters are intended to be combined (one glyph overlaid onto another, similar to प + े = पे).
This works fine when I import the font into a document editor, for instance, Libre Office. It also works fine when I type the script in a textarea in Google Chrome.
However, when the font is used in a textarea in Firefox, a tiny increment is made after each character, even though the horizontal advance is set to 0 in the TTF font file data.
This seems to be something built into Firefox, but it makes the combining look a bit off, and, if I wanted to overlay several characters on each other, it would look very bad. I think I read somewhere that Firefox knows to turn this off for certain fonts, but I cannot figure out how to do it. Or perhaps there's something in the CSS styling for the textarea? I'm at a loss.
Does CSS letter-spacing: 0; make it what it should be, or messing with that negative or positive get you anywhere?
Or check out the property font-kerning as well.
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”).
My client (who is obsessed with pixel perfection) dislikes the way browsers render font-face fonts.
At the moment I am using font-squirrel to convert OTF fonts to webfonts.
The problem is, I don't see any alternatives. I could create a PNG file holding all these texts, but that doesn't sound like a browser-user-friendly solution.
The typical example of a design I have to work on is:
What would be your approach?
I'm assuming that by "dislikes the way browsers render #font-face" your'e referring to the blink which happens. If not, you should elaborate.
The top one is web-font and the bottom one is screengrab from PSD. Both using same font family, same spacing. The client wants to look it more like the bottom one.
I'm assuming that by "dislikes the way browsers render #font-face" your'e referring to the blink which happens. If not, you should elaborate.
Currently there's only 3 options to remove that blink. The first two are obvious solutions - use images, or use web safe fonts. These, obviously, defeat the purpose.
The third option is to embed base64 code for the fonts in your CSS. This increases the size (kb) of your CSS files, but it will completely eliminate the blink which tends to occur because the font is loaded with the CSS so there's no blink when a secondary file is loaded.
usage for including bas64 fonts looks like this:
#font-face {
font-family: "FontName";
src: url("data:font/opentype;base64,[ the base64 code here ]");
}
There are a few online bas64 converters that you can feed a .otf file to and they'll spit out the base64 code. Here's one such converter.
An approach that I have used is to create background images to represent all display-text, and then use CSS to "hide" the actual text, and show only the image. For the sake of accessibility, the text should not be hidden using display:none or display:hidden though. Instead, use a large negative text indent to move the text off the left side of the display, or put it in a nested, absolutely-positioned element somewhere outside of the display area.
I usually use the negative indentation for all text not contained in a clickable element, and the nested, absolutely positioned element technique for anything that is contained in a clickable element (so the active element outline does not expand off the left side as can happen in some browsers).
Another common and popular way of handling this is automatic font replacement (using JavaScript). This solution is friendly to users of screen readers, because the HTML contains plain text and the replacement is done using JavaScript, in the browser.
An example of this is technique is sIFR, which is open source and uses Flash as the replacement.
It looks like it has been bolded. Try setting font-weight to normal.
I'm working on an ASP.NET website that needs to be internationalized. I'm using .resx files (essentially key-value pairs in a file) to populate static string fields on a page in different languages depending on the chosen culture/locale. I'm implementing Japanese and getting some stubborn vertical strings.
When copy and pasting them into the .resx file, they are horizontal (source of strings is Google Translate, for testing purposes). All of the strings appear normal, but one always displays vertically. The misbehaving string is a few div's deep (like all of them) and only has font-size, font-family, color, and an uppercase transform applied to it.
Removing any or all of the above rules does not change the orientation of the text. I've cleaned the formatting off the offending text with Notepad and shortened it (to ensure it wasn't a length problem). I'm stumped as to why this particular string is stubbornly vertical.
Here is the text in question: ログアウト
(Translation: Logout)
Edit
Clarification of the issue.
What it should look like:
The vertical text in question:
How can I force vertical text to be
horizontal?
Other than the title, I don't really understand your question. I'll take a guess anyway.
Try adding white-space: nowrap to the div that's misbehaving.
Recently I was doing some learning about right-to-left on the web and learned that Unicode characters have a directional property associated with them at the character level. So this might have something to do with that, though I certanily wouldn't know how to ascertain that or fix it, especially given that Google Translate is the source of the strings.
It happens quite often for Asian scripts (not just Japanese but also Korean and Chinese) to have text rendered incorrectly. Usually you just need to play with element width, especially if it is part of HTML table.
...regardless of font size.
Its an mx:Text object. (The Text object is actually being used as a mask so don't know if that's the problem.) If underline is set with the <u> tag in Text.htmlText, or Text.textField.setTextFormat, the underline thickness is always just one pixel which is not acceptable. (There are other problems with <u> so I'm limited to using setTextFormat currently.)
Can the thickness of an underline be set through CSS? (textField.styleSheet, etc.)
I may have another problem as I already use setTextFormat extensively, and the documentation says you can't use textField.setTextFormat if you use textField.setStyleSheet.
I primarily need the underline to simulate correctly the look for an anchor tag.
its not even possible to do in html (you need to use border-bottom). i don't think this is possible.
Not possible with CSS or TextFormat.
A possible workaround would be using the textfield metrics (probably through getCharBoundaries()) to manually draw a line under the desired text. It can get quite messy for multiline text though.