I'm trying to use the Oxygen font from Google Fonts in my website, but I'm having strange problems with it.
Firstly, it doesn't seem to want to render at certain sizes, like I can't make it 19px. It will do 18px or 20px, but not 19px.
I also notice that the heights of the letters are borked. Take a look at the attached pic, how the 'S' is out. That's a screengrab of the font at 19pt. However, everything is 18px tall except the 'S' which is the one thing that sticks out to 19px.
And at larger sizes to this, other letters start antialiasing oddly too.
Whether I try ems or pxs or pts, I'm getting these glitches.
If you go to Google Fonts and search for Oxygen at the left and type in some text at larger sizes, it does the same thing, strange S's, etc. But strangely, if you search for specimens of this font in Google Images, it seems to render and antialias much better than this (Oxygen specimens in Google Images). Any way to fix it or is this font broken at source?
I hate to tell you but the font is broken at the source. It was obviously made unprofessionally or designed to be exactly that way. I'd recommend just using a new font or dealing with it as a regular user wont exactly mind it. Maybe a web analyst would but it's a nice font to a normal user.
Related
I'm experiencing an odd rendering problem in SOME versions of Chrome when trying to render the unicode characters U+2795 thru U+2797, the Heavy Plus/Minus/Division Signs. On some versions of Chrome, the sign will render as an ugly gray with some kind of black pseudo-outline, which does not respond to CSS color commands. Here is an image:
For a sample of how it looks on every other browser I've tried, see FileFormat.info - Unicode Character HEAVY PLUS SIGN
By SOME versions, I mean, I can't seem to narrow it down to a particular version of Chrome. The same version of Chrome on two different computers running Win10 will render differently, and I can't find where the difference is.
Is this a bug in Chrome? I can't seem to find where anyone else has run into this problem. I'm trying to include this on a website, but if certain versions of Chrome render it ugly, I need to find another solution.
-- edit --
XY Problem
My purpose is to use the +/- as the "expand/collapse" markers in a collapsible accordion box where the background may be light-colored or dark-colored. I was hoping to be able to color them to match the remainder of the text without needing to resort to images, but based on the comments below I'm starting to think it may be easier to throw together an .svg, recolor it in CSS, and be done with it.
The problem is that the browser is replacing the glyphs with emoji, which will be rendered differently for each browser. Emoji cannot be colored using CSS -- the best you can do is silhouette them and color the silhouette, as described in Color for Unicode Emoji. Unfortunately, this still means that the glyphs will appear differently on different browsers, as the emoji won't render using the font you specify.
There isn't currently a way to force browsers to render glyphs instead of emoji. Appending \FE0E (as described in How to prevent Unicode characters from rendering as emoji in HTML from JavaScript?) will sometimes work, but this is not consistent, not guaranteed, and therefore not recommended.
You can provide a web font which contain the glyphs you need, but this is also not guaranteed to work, as some browsers (especially on mobile devices) will still replace them with emoji.
If you require consistent rendering, the best way seems to be to use an image instead of trying to force the browser not to use an emoji.
Just like I have mentioned in the title.
How do you guys manage the fonts , when you do a web design
because different browsers even you set equal in pixel but the result seems to be different.
It makes other element collapse with the things I have designed.
so please advice me.
Eg: most browsers are okay , but IE is bad.The fonts appear to be very big than in others.
For main body text, you don't. Some people want bigger text so they can read it more easily; get in their way at your peril. Use relative font sizes in units such as ‘em’ or ‘%’.
For small amounts of presentational text where you need text size to match pixel-sized on-screen elements, use the ‘px’ unit. Don't use ‘pt’ - that only makes sense for printing, it'll resize more-or-less randomly when viewed on-screen.
You can still never get the text exactly the same size because fonts differ across platforms—and Lucida Grande and Helvetica look very different of course.
I have a few links that are slightly smaller (at their bottom part) than the rest of the text and I don't understand why is that and what I did wrong that could have caused this.
The problem exists here on following links: github, link, email, comment and lab.
If i move the list outside of #top_container, then the size becomes normal and the weird spacing at the bottom of these links disappears.
Does anyone have an idea of what I did wrong? Thanks.
What you see is, actually, an optical illusion generated by the contrast between white and red fonts. Also, you use bold fonts for links which only add to the impression that these fonts are smaller. Try changing their colors and weight.
I've uploaded a screenshot of a fragment of your page. That line can be used as a base to compare a little more accurately these fonts. Hope it helps.
EDIT. I use Firefox. Maybe in other browsers bold fonts are rendered a little different and the discrepancy is real (not an optical illusion as I've supposed the first time).
Can someone look at this page carefully. I am trying to fix font on this page. I don't know what previous programmer has done to font. Can you look at service guarantee and service features headings in green panels, edges of text are like someone cut this font with seesaw. Similarly on other parts of page. They are supposed to look smooth.
viewing page on ff and ie8 (widows xp).
I think you mean that these sections aren't anti-aliased. This isn't something you can control when you display text on the browser -- it's actually browser- and OS-dependent.
If it's important to your users to have smooth fonts, then you could anti-alias them in an image program and use images instead of text, but this is extremely inefficient and makes your page a gigantic pain to update.
So, in short, there isn't anything you can do to fix this. See this SO question for more details.
use firebug which is a firefox plugin to see the styles and html tags used in the web page, you can even edit the css used in the web page through firebug.
Your page looks fine on my browser (Chrome under Windows).
Different browsers all render text differently. What you will find is that there are often sweet spots in font sizes that look better than others. In any case, what you are talking about is whether the browser is displaying fonts anti-aliased or not.
There is a CSS3 property, font-smooth, that you can adjust for this, but don't expect it to work on browsers that aren't smoothing their fonts anyway. You can read about it here: http://webdesign.about.com/od/styleproperties/p/blspfontsmooth.htm
In short, don't worry about it. If it is a big deal for you, then experiment with different fonts and sizes. A good tool for doing this is at http://www.typetester.org/
Don't forget to test your site at BrowserShots.org. It will do screen captures for you, so you can check these details on a wide range of platforms.
If you must have your font rendered in a specific way, then it must be done in an image. This is not recommended. Text should be text wherever possible. However, if you must do it this way, consider one of the many scripts that assist, so you can keep text for browsers that don't support the script, and SEO isn't a problem. Typeface.js is commonly used for this.
While generating charts using RS 2008 betas, RC0 and such., I never specified any fonts for axis labels, legends etc. They were all rendered with the Arial font by default, which looked awesome. But as soon as we switched to RS 2008 final, the fonts got all messed up - they are rendered in some kind of bold console font.
My initial thought was that the default changed - I tried setting the font to Arial explicitly (either through RDL or the designer). That didn't work - only certain fonts seem to work (e.g. Calibri). What's even more weird, the legend does not listen to the font setting - it is always rendered in this ugly bold thing.
One other thought was maybe the fonts are missing somewhere, however, the Tablix element is using the same fonts and they seem to work.
This behaviour is universal - it is seen using the development studio preview, the report viewing control and while exporting it to all available formats.
So, obviously, I'm stuck - has anyone ever encountered this behaviour ?
I have seen this behaviour before. Not in SSRS, but in GDI+ rendering in .NET desktop applications. It has to do with antialiasing and palettes that don't support transparency - all the nearly-transparent pixels surrounding the glyphs are coerced to solid colour.
You don't get this effect with post-LCD fonts like Calibri because they are aligned to pixel boundaries for better rendering on LCD displays, which have sharply defined pixels. CRTs allowed colour to bleed into adjacent pixels, producing what was essentially analog antialiasing. (This is why TV pictures look much better than they should considering their horribly low resolution.)
I did find a way around it with GDI, and when I remember I'll tell you. That said, you don't have access to the rendering code so you probably can't apply the fix. Actually I think I've just remembered - you explicitly set the background to white rather than transparent, forcing GDI to composit the edge colours instead of hoping the graphics card will do it. I don't know whether you'll be able to use this answer, sorry.