I am having a lot of trouble vertically aligning an entypo icon font.
Here is the codepen which currently displays as intended on Safari and Chrome on mac - http://codepen.io/anon/pen/jJtwz
As you can see the right arrow is vertically centred. Now the problem browsers...
Mac Firefox - The arrow is slightly lower but can tolerate this
It appears too low on the following browsers... (Every PC browser)
Mac Opera PC Chrome PC Firefox PC IE 10 PC IE 9
All the PC browsers seem to be resolved by adding a line-height:5px and getting rid of the top value.
Has anyone experienced the line height inconsistencies between browsers with icon fonts and know of a fix? It seems the OS has something to do with this as opposed to just browser inconsistencies.
I have tried all sorts of tricks like negative margins, absolute/relative positioning but cannot get consistent results.
Thanks
P.S. This was tested on all latest versions of browsers on the latest Mac OS and Windows 8
Here is the code if you cant view the link...
HTML
<section class="hbox hshop cfix">
<img src="http://placekitten.com/g/600/400">
<h3>Clothing</h3>
</section>
CSS
.hshop > a {
display: block;
border: 1px solid #ccc;
}
.hshop > a >img {
vertical-align: bottom;
padding: 0.75em 0.75em 0;
}
.hshop > a > h3 {
padding: 0.5em 0.6em;
position: relative;
font-weight: normal;
}
.hshop h3:after {
content: '\E766';
font-family: 'entypo';
position: absolute;
right: 0.3em;
font-size: 2em;
top:3px;
}
img {max-width:100%}
It was an entypo problem. The spacing around their glyphs was causing the issue. I used the icon fonts from fontello and this worked http://codepen.io/anon/pen/sidje
There are still inconsistencies in that entypo font. In all icon fonts.
The best solution I have found is set a baseline font size, and play around with you font metrics until you get something semi consistent Matching the base font metrics is a good start .This method works best if you keep the same size icon-font, changing the size throws everything off.
Also IE reacted better when I set the line-height a little smaller then the font size.
Really sloppy, but it got me close enough.
I fixed the font vertical space oiand made it available here https://github.com/zenx/entypo
Related
I've seen this 'FontAwesome icons looks pixelated/blurred' issue various times on stackoverflow or their github but none of the solutions worked out for me.
Here is an example:
https://plnkr.co/edit/CmviS7TuPcIJX20G?preview
The top 3 list items use Font-Awesome to create a 'fancy checkbox' while bottom 3 list items use a regular border-radius (and some transformed rectangles to form the checkbox... not optimal).
The bottom 3 border-radius list-items looks much better to me than the top 3 FontAwesome ones (but the form framework we using uses Font-Awesome so hoping to just fix it with some simple CSS fix).
I checked latest version of Chrome/Firefox/Edge/Opera (on Window7)...
The top 3 list-items which use Font-Awesome look a bit jagged on all browsers (especially the main white circle). Attached is a pic:
I'm using FontAwesome 4.3 but seems like people had the same type of issues in Font-Awesome 5 as well (believe I tried that FontAwesome 5 file as well to no avail).
Things I've tried which seen on other posts:
put the SVG font file higher up in the #font-face css rule in the
font-awesome.css file (i tried that locally on my computer but that
didn't work).
adding something like "-webkit-font-smoothing:
antialiased;"
adding a temporary tranform onto the checkbox item
like "transform:rotateZ(0.5);"
use a font-size in a multiple of 12px or 14px or 16px (depending on which version of Font-Awesome using). For this example, I used 14px since that seems to be the base font-size for .fa.
Open to suggestions to try,
Thanks!
Have to post some code if I am linking to a plunkr so here is the main CSS for the Font-Awesome items:
.has-font-awesome li:before {
font-family: FontAwesome;
font-size: 48px;
content: '\f111';
color: white;
position: absolute;
top: 0px;
left: 0px;
}
.has-font-awesome li:after {
font-family: FontAwesome;
font-size: 36px;
content: '\f00c';
color: black;
position: absolute;
top: 7px;
left: 3px;
}
After enabling Windows ClearType, and restarting computer then the FontAwesome icons look as crystal clear as the border-radius icon:
Looks great on all 4 browsers now.
Apparently "ClearType is enabled by default in Windows 7, 8, and 10".
So maybe i turned it off.
Hoping someone here has seen this before. I have a site that required me to remove the default bullet points and replace them in css, on every browser and mobile device it shows up the way I've style it to aside from IOS.
I've checked safari and chrome on my iphone 6s and in the list where I replaced the bullets with a white box it's changing it to a rather large box with a black gradient.
This is how it looks on a pc/android - the bullets are orange which is the desired colour
An this is how its displaying on all IOS mobile browsers:
This is the css that I'm using for the bullets:
section.specificationsSection ul li:before {
content: "\25AA";
font-size: 37px;
display: inline-block;
width: auto;
line-height: 15px;
margin-left: -.8em;
color: #f15822;
margin-right: 8px;
margin-top: 4px;
}
I'm stumped, I've looked around to see if anyone else has seen this, asked a few designers and developers with no luck, any help is welcome! thank you.
iOS may be replacing the "\25AA" entity with a black square emoji? (reference: https://www.iemoji.com/view/emoji/521/symbols/black-small-square)
We had this issue as well. We switched to "\25FC", which looks similar to "\25AA" and avoids the huge, beveled look on iOS. We've only needed to use it in black color, though.
For an online demo (project) I wosh to pretend an LCD display. I found a fine 7segment font https://fontlibrary.org/en/font/segment7 . One of it's fetures is that the decimal dot uses some kind of "negative kerning" (or letter-spacing, please apologize my lack of terminology), so it visually belongs to previous number. This is desired behaviour.
However, this behaviour works only in FF & Chrome, not in Edge/IE (
see https://jsfiddle.net/jan_koupil/o1c8srt1/2/)
#import url(//fontlibrary.org/face/segment7);
#display {
font-family: 'Segment7Standard', sans-serif;
font-size: 30px;
border: 1px solid black;
padding: 3px 5px 1px;
width: 142px;
text-align: right;
}
…
<div id="display">8.8.8.8.8.8.8.8.</div>
For these browsers I need to switch the font to a different variant or at least reduce font size in order to fit into the fixed size display DIV. My trouble is that everybody recommends testing features, not browser versions but I don't know which feature to test.
This could be due to missing kerning in Internet Explorer. See this answer on how to explicitly add kerning to the text rendering for IE. You might also check other Opentype features and how they are activated via CSS.
I'm working on a typography-focused website and stumbled upon a major font rendering issue with Safari (9.0.3) on OS X El Capitan.
I think Safari is known to have problems with Glyphs that go outside of the font files Bearing Bars, especially on hover changes.
I found a workarounds for that, but I still have issues with plain text inside a div-block:
http://jsfiddle.net/bRs3Q/9/
CSS
body{
font-size:120px;
text-align: center;
text-transform: uppercase;
font-family: Arial;
font-style:italic;
}
.text{
display:block;
width:80%;
margin:0px auto;
}
Safari always cuts the font right before one line is nearing a line-break and at the exact point where the glyph is going out of the font-files bounding box.
Is there a way of changing the font-rendering oder manipulating the line-break?
I had a similar problem with an own font.
You might be able to fix it the same way i did:
Add i.e. 20px padding and -20px margin.
See also:
Chrome cuts off parts of type on the left, firefox and IE display fine. Chrome bug?
Had the same issue where the uppercase char (or other characters) was cut off at the top.
The cut off was not so big, so making some spacing (like previously comment suggestion) at the top with padding-top: 10px (or whatever value is needed) is doing the work.
The green padding area wasn't visible before that.
I'm trying to get a semi-transparent background that "follows" the text: i.e. the background should not be a rectangular box, but rather a "jagged box" that stops at each linebreak.
Like this:
I do this with the following style:
p {
display: inline;
background-color: rgba(0, 0, 0, 0.5);
font-family: "Montserrat";
font-size: 18px;
/* Add spacing between lines */
line-height: 28px;
/* Make sure background covers space between lines */
padding-bottom: 6px;
}
An example can be seen here: http://jsbin.com/texala/6
The problem is that Firefox and Chrome renders these differently. The two browsers are using the exact same .woff font (not .woff2) and trying all different resets from cssreset.com still doesn't work.
The problem
What you can see here is that the background from each line is overlapping in Firefox but not in Chrome.
I'm using OS X 10.7.5 with Firefox 35.0.1 and Chrome 40.0.22.14.111
I know that font rendering is different from platform to platform and browser to browser, but with an explicitly set line-height and font-size (and padding) in pixels -- isn't one of these two renderings wrong?
Furthermore - does anyone have a solution to this problem so that the background covers all the space between the lines with no overlap in both Chrome and Firefox?
Maybe with other line-height?:
p {line-height: 158%;}
Positioning of the CSS reset within the entire document structure is key. However, for this specifically,
p{display:inherit;text-align:justify};
Edit
Read up on using EM and REM. It is superior to pixels in every way.
p{line-height:1.61em};