I must have went through every page of google but haven't found the solution yet. I have a custom font that I'm using through css font-face. The font adds extra padding on the bottom depending on the browser and OS that I am using. The picture below shows an example with mac being on the left and windows on the right. It looks correct on the right (in windows) and i want it to be the same on mac.
#font-face
{
font-family: universLight;
src: url('http://www.viggi.com/fonts/UniversLTStd-Light.otf');
font-weight: normal;
font-style: normal;
}
#button{
font-family: universLight;
border: 1px solid black;
background: #ccc;
}
The code is located at http://jsfiddle.net/ZDh5h/
Here is what I already know won't work from my research.
line-height adds padding to the top and bottom so the extra padding on the bottom remains.
using different extensions such as .otf or .ttf also doesn't work. Just produces the same results
changing the font-size also doesn't really do anything
I use this font a lot through out the site and don't really want to add different CSS sheets for mac vs windows. If anyone knows anyway to fix this without having javascript add extra padding I will be very grateful.
Thank you.
See http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
normal
Tells user agents to set the used value to a "reasonable" value
based on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
The computed value is 'normal'.
I think the behaviour you observe comes from different "reasonable" values across browser as normal is the default line-height value.
So specify your value (say line-height: 1.5em;) to get rid of the differences.
Related
I'm using this CSS to style a div:
#mainSection .mainArticle .text {
width: 600px;
margin-top: 0px;
margin-left: 20px;
line-height: 26px;
color: white;
float: left;
font-family: 'Open Sans', sans-serif;
font-size: 15px;
}
The image below shows the difference between Safari and Chrome:
I can't tell why it's this different. The font looks 'bolder' in Chrome, yet each character takes an tiny bigger length in Safari, meaning it sticks on average less chars on each line. Because the div box size is fixed length, the result is that the text ends too close to the bottom border.
I can't have variable length boxes. You can see the site here (go to MENTORING section):
enter link description here
Is there a convenient way around this problem? I know the font engine is different for each browser...
i think it is because the browser size is not same for all the browsers, and you have defined your CSS in terms of pixels., try to convert from pixels(px) to percentage(%) or em/rem values.
i hope this helps.
Safari renders open sans bolder than in chrome so you would need to apply a lighter font weight for safari Open Sans Google Web Fonts Rendering in Chrome
The reason is that whereas other browsers render the font at the exact size specified, Safari renders fonts in a series of steps.
I assume that the Apple team feels that fonts rendered at 10.3px look better than fonts that are rendered at 10.0px. (made up values).
The consequence is that you get different results between Safari and other browsers.
The easiest way to see this in action is to define a font size as a percentage, then slowly resize the window:
Test page at svija.love
In other browsers, the font will resize smoothly with the window. In Safari, the font size will increase in a series of jumps.
I am looking for a workaround for this (help, somebody!) because this behavior is screwing up my layouts and making it look like I have spelling errors at Ozake.com.
[update fall 2021] I wrote a program that combines the various text blocks into a single line, eliminating spacing problems. See svija.love for more information.
I've seen a few issues with the cursor being improperly spaced in the ace editor. The problem has to do with the font-spacing and apparently the solution is to only use monospaced fonts.
Here's another SO question about the issue.
ace editor cursor behaves incorrectly
My problem may have something to do with using a Bootstrap theme, but I'm not entirely sure.
When I open chrome dev tools and look at the font used in the ace editor, it says that my Bootstrap template is using the fonts
input, textarea, input[type="submit"]:focus, div {
outline: 0 none;
font-family: 'Open Sans', sans-serif;
}
If I add to my css
.ace-editor {
font-family: monospace !important;
}
I still have a problem with the cursor spacing being wrong, and strangely, the font which is being used looks exactly the same as the 'Open Sans' defined in Bootstrap.
Opening in Chrome dev tools, says that the computed property is 'monospace', so something is supposed to be working, but it isn't. Here is where it get really weird.
If I remove the font entries for both .ace-editor and input, textarea..., I get a perfectly good looking font that works.
Going to the computed properties, is shows the font-family to once again be 'Open Sans'.
So the question I'm trying to answer, is how can I either figure out what font is ACTUALLY being used when I cancel out the textarea entry from Bootstrap? Or why is this not accepting the monospace font when it is specified.
I'm somewhat assuming that 'Open Sans' may be monospaced, but whatever, it's still causing massive headaches.
The issue is caused by div included in bootstrap rule.
It is too broad and breaks character width measurements for ace.
You can add
.ace_editor div {
font: inherit!important
}
as a workaround. Would be good to also report an issue to the creator of your bootstrap template.
I was wondering if someone could point me in the right direction. I am looking to display the Google Font Orbitron at consistent weights at every given font size. Sounds pretty easy, right? Not in my scenario. At certain font-sizes, some characters have multiple weights within the same character.
Note: I am testing this in Windows 7, Chrome v27
The Code:
<link href='http://fonts.googleapis.com/css?family=Orbitron:400,500,700,900' rel='stylesheet' type='text/css'>
.sixteen{
font-family: Orbitron;
font-weight: 400;
font-size: 16px;
line-height: 22px;
}
.nineteen{
font-family: Orbitron;
font-weight: 400;
font-size: 19px;
line-height: 22px;
}
<h4 class="sixteen">Home of Front End Developer and</h4>
<h4 class="nineteen">Home of Front End Developer and</h4>
Here is a fiddle to explain my issue. If you take a look at the fiddle, you'll see in the first line that the top line of the uppercase F, E, and D characters have more weight/thickness than the rest of the characters in that line. But as you'll notice on the next line, that
In case you cannot replicate what I'm seeing, here's a screenshot:
My question is two-fold:
What would the best way to technically describe this? 'Multiple font weights in one given character' lacks brevity, and isn't likely to have any valuable Google results.
Is there a way to fix this and make the weight consistent in every character at every font-size?
What you describe is as such just variation of the visible width of strokes in glyphs, or stroke width variation to put it briefly. Such variation is normal in serif fonts and also appears, at least to some extent, in many sans-serif fonts. However, in this case, the font is designed to have a rather constant stroke width, so the visible effect is caused by font rendering differences.
There is no way to remove the font rendering differences. Font rendering is a complex issue, and although some proposed or experimental CSS settings might affect some aspects of it, it’s basically outside your control. For example, font smoothing (also known as anti-aliasing) depends on the operating system and its settings as well as the browser and its settings.
I've found this issue with a bunch of fonts used online when you go down to a certain size. It's the way the font is being anti-aliased.
You can see the same issue from Google showing off that font: http://www.google.com/fonts/specimen/Orbitron
I've began working on a new site using REM units with PX fallbacks. Now, I have a question that may be silly, but I can't find anything specifically mentioning it so I'll just go ahead and ask here.
Using property shorthands and specific properties seems to both load take effect in the browser Chrome.
body{ font:16px/23px sans-serif;
font-size:1rem;
line-height:1.438; }
whereas using both shorthand or both specific properties cancels one or the other out (e.g. uses primary or fallback, not both)
body{ font-family:sans-serif;
font-size:16px; font-size:1rem;
line-height:23px; line-height:1.438; }
or
body{ font:16px/23px sans-serif;
font:1rem/1.438 sans-serif; }
Now which is exactly best practice here? All examples validate.
Is there a reason why the shorthands AND specific properties both load in the browser Chrome even though they're targeting the same properties? Are they actually both loading?
Does this have any adverse effects to how the browser/device is rendering the styles?
I've only looked into this via Chrome and I haven't been able to discern any differences through testing. But, You can see how it would be a little bulky if you HAD to use two iterations of the same code for all elements using rem's.
UPDATE:
Tested only in latest versions of all browsers below, all tests pertain to the first code snippet
In Firefox this doesn't seem to be an issue, it just replaces the font-size/line-height in the shorthand code with the rem sizing.
In IE, safari, & Opera it takes the shortcode and separates it into specific properties, but still loads the rem units ignoring the px units.
It seems to be specific to Chrome, at least in modern versions. So the question now, how to figure out how Chrome is handling it? The image, displayed at the bottom of this post, may explain a little more. See how BOTH font properties are loaded and neither are ignored or take precedence?
UPDATE#2:
When using margins, Chrome acts properly. I'll use the following "off the wall" example to demonstrate:
margin:16px 0 19px 0;
margin-top:1rem;
margin-bottom:1.188rem;
reads in chrome as:
margin:1em 0 1.188rem 0;
(source: leftdeaf.com)
This two resources will answer all of your questions:
http://snook.ca/archives/html_and_css/font-size-with-rem
http://blog.typekit.com/2011/11/09/type-study-sizing-the-legible-letter/
With line-height, use the unit, but not the value:
body {
font:16px/23px sans-serif;
font: 1rem sans-serif;
line-height:1.438;
}
or
body {
font-size:16px/23px;
font-size: 1rem;
font-family: sans-serif;
line-height:1.438;
}
You can't use FONT and FONT-SIZE, just use one or the other. Otherwise the browser will attempt to use both.
After a lot of wasted time and confusion... It actually does render correctly in Google Chrome. feeling silly now... I overlooked the drop-down arrow to the sub-properties in the Chrome Tools. Image displays what I overlooked. Example shows multiple examples of shorthand properties and specific properties, more importantly it shows the font property working, it wasn't crossed out but it was still being overridden. Not sure why it doesn't comply with the strike through like everything else, probably due to the font-weight, variant, style properties remaining unchanged. But it works.
Image below displays the result for:
div.test { background: #00F; font-size: 50px; line-height: 50px; color: #FFF; margin: 50px 0; font-family: Wiesbaden; }
One using Wiesbaden (which is font-face) and the other without.font-face font seem to ignore the line-height property.
Is it font-face issue or the font?
The property line-height only specifies the vertical distance between the start of one line and the start of the next. If you typed out something that took up two lines, the start of the 2nd line should be in the same vertical position using either font.
It seems like that's just how your font looks at 'font-size: 50px'. If you wanted to, you could increase the font-size while keeping line-height: 50px to correct it.
In short, it's not an issue with either. They're behaving exactly how they should be. See your blue background? That's your line-height. Line-height doesn't affect the font itself, but rather the spacing of the lines of the text.
Some fonts are different sizes even when set to the same font-size. It's the way the glyphs are rendered. If you want your text larger, increase the font size. If you want fallbacks to be the same size, you can use similarly-sized fonts (look up "font stack generators" for help on this), or check out the CSS3 font-size-adjust property (do note that it is CSS3, so you'll want to double-check support of it).
I had a similar issue, but I used a Cufon script instead of fontface to avoid browsers issues. To solve my line-height issue I changed the doctype from transitional to strict. Try that.
The following fiddle illustrates the differences between 4 fonts (3 being very common fonts found on Macs, PCs, etc). One is a Google-font. Regardless, 4 fonts - four different results. If a design is going to rely heavily on a 'non-standard' font, be sure the fallbacks don't blow the whole thing up.
Pay particular attention to the differences in:
the top spacing between the capital Q and its parent's border
the various heights of the Xx (especially, the lower-case vs capital)
descender of the lower-case G (some actually come out of their
parent)
_http://jsfiddle.net/suK2U/
I tried this and it works perfectly!! just play with percentage until you find the needed result.
Apply this on your #font-face:
ascent-override: 90%;
Hope it helps!
More info:
https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face/ascent-override