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.
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.
Had this issue when working with report viewer - now having the same issue with SSRS. Basically what happens is I create a report with a certain font - it looks perfect in the preview mode - however, when I go to print it - it makes the text look different - kind of squeezed and looks to be complete different font as a matter of fact. Included image with what it looks like in PREVIEW and PRINT.
Anyone had an issue like this before?
Thank you.
This page and many similar ones give information about rendering, but none of them seem to answer the questions "does this text fit in this box?" and "How big will this box be?" Rendering to IE, Chrome, Safari, Word, and PDF was an exercise in frustration and compromise, especially considering that Visual Studio and Report Builder were also different. In all cases, the height and width of the text boxes changed, the font size changed, and the spacing around the text changed.
Our technique was to prioritize the various output formats, then find settings that produced the best output based on those priorities. Given this, users see better (but still not quite perfect) results than we see in Visual Studio.
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.
For specific reasons, I need to be able to display some values on the bottom half of my report upside down(inverted). The intention of this report is to be printed and folded down the middle, so I would like for it to adhere to this specific format. I can't find anything that does this easily. Some ideas that I have considered but don't know how to implement:
'importing' an upside-down font and setting the control's font to that font?
somehow inverting the entire control 180 degrees
Does anyone have any experience accomplishing this?
Edit: installing an upside down font and setting the control source's font property to that font was the solution that I implemented. For some upside down fonts, it may be necessary to call str_reverse on the text, as the upside down font may reverse the order Problem is-- This would only work on the computer with the font installed, right?
I think your options are:
Lebans: http://www.lebans.com/
Word mail merge
An upside down font
An image.
Access has a Vertical property, but that is only for 90°.
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.