We haven't found anything anywhere so far about that very strange effect.
For some time (don't know since when exactly), the capital S letter renders in Windows browsers like it's been moved by one or two pixels to the right. This happens on many browsers, not just on my system, so our customer wants it repaired. It's not a question about local Windows configuration but about browser rendering.
It can be seen here: http://www.holcimfoundation.org/T154/holcim_awards.htm
Here are some facts:
On Mac, Linux, Android and Windows with ClearType switched off the effect doesn't occur
If zoomed in (CTRL+ on Firefox), the effect gets smaller and then disappears
It doesn't happen on every website, just a few - I believe I've seen this elsewhere too (but didn't keep the URLs)
We believe that this is a bug in the Windows font rendering engine. Does anyone have any idea why this happens? Or what kind of workaround we could use?
On Mac, Linux, Android and Windows with ClearType switched off the effect doesn't
I'm not much of a ClearType wizard on Mac, Linux or Android but in Windows you can tune it.
If zoomed in (CTRL+ on Firefox), the effect gets smaller and then disappears
To me this indicates that the text path is being rendered correctly but at 100% with so few pixels to work with the "mapping" is wrong. Do you have a problem with this at 72pt?
We believe that this is a bug in the Windows font rendering engine
Do you have a reference rendering to compare this bug to? For all intents are purposes it could be by design, or your ClearType could be misconfigured.
EDIT:
I looked at this using the "Inspect Element" feature of Chrome. It seems you are trying to do too much with only 10 pixels of character real estate.
Observe the style and the rendering before:
Now take bold off:
Looks like it's not a bug, ClearType is doing the best it can with only 10 pixels.
Related
I'm trying to make VS Code editor to look exactly like Visual Studio. I made sure the font settings are exactly the same, however text still renders differently in VS Code (it seems "lighter").
Is there any way to fix this issue?
In the image below the top text is copied from Visual Studio while the bottom one is copied from VS code.
I know the difference is subtle but is still pretty noticeable.
Font rendering in VSCode has been a reoccurring issue throughout a good portion of the editors life time. Font rendering, especially in portable GUI's, is affected by several different layers, for example:
Your Graphics Card can affect the way font is rendered (you can try adjusting the graphic cards settings manually).
Your Monitor, obviously, affects rendering. In fact your monitor has a huge impact. (Try playing with your Monitor's Settings)
The color settings that are offered by your OS may have an impact (often times the color settings are the same as the graphic card settings though. Which means you can just use your OS's GUI to adjust your cards settings in some cases (Not on Ubuntu though))_
Somethings are out of your control, like:
VSCode, it is written using Electron v6. Not only does Electron impact font rendering, but when VSCode switched it Version 6 a lot of people reported a decrease in the editors font rendering quality.
VSCode also implements Anti-Aliasing tools, but as far as I can tell, they auto configure, so you have no control over this. These tools are likely to be one of the biggest causes to the difference in rendering you see, between VS IDE & VS CODE. There is a tool however that may give you some control over the Visual Studio side of rendering that I share a link to below. And just as an FYI, the Anti-Aliasing that VSCode uses is called Sub-pixel Rendering, which is something that Visual Studio doesn't implement as far as I can tell.
The Area You Have the Most Control in:
There is ONE tool/thing that you have 100% control over, that also greatly affects font-rendering, and that is the font that you decide to use. When choosing a font, you have the choice of equipping an OTF, or a TTF. In my personal experience, OTF's render better 90% of the time. The difference is in how they are created.
TTF fonts are made using quadratic Beziers.
OTF fonts are made using cubic Beziers.
Links above are the same
Fonts use something called font-hinting
Font hinting. Essentially font-hinting is a list of instructions that dynamically changes the way a font is rendered, by using the rasterized grid background as a parameter. adjust the display of an outline font so that it lines up with a rasterized grid. Choosing a quality font equipped with good hinting is critical for non-blurry readable text.
Many people choose font because like the way they look, or the italic version of the font they use is popular. When choosing a font, it is extremely important to choose, not the coolest one, but the one that renders with the highest quality, and is the easiest for you to read.
Well Rendering Fonts:
Not only are their fonts that render well, with ligature support, but the best rendering fonts are always free IMO. Bellow are Fonts that use font hinting and have top notch rendering abilities.
JetBrains Mono (JetBrain's Font & My Personal Favorite)
Cascadia Code (Microsoft's Programming Font from 2019)
Fira Code (Not that old, but not that new either. Is loved by many.)
Fira Mono (No Ligatures, Different Font than Fira Code)
Consolas (A classic)
Menlo (Another Classic)
The top 4 are at the top of the list because they receive updates ever few months. I don't think Menlo & Consolas receive regular updates, but they aren't left forgotten either, the are updated every year or two.
To finish with as solid of an answer as I can provide:
_"Getting VSCode to render like the Visual Studio IDE, is not something that you will probably get, with 100% satisfaction, getting an exact match with all of the different factors is just an extremely and possibly impossible thing to due. You can probably make the way the two pieces of software render, more a like, not in functionality, but in looks. It would probably help a great deal to make sure that everything that affects rendering is up to date, editor, IDE, fonts, tools, ect... From their you can try different versions, and see if maybe an older version of VSCode rendered in a way that is preferable to you. You should also play with your monitors settings. I have found that I can accomplish a great deal just through the buttons under the face of my monitor. Check Visual Studio for any rendering settings it might have, VSCode doesn't have much available, but maybe Visual Studio IDE does (I haven't used the IDE in 5 years so IDK if it does).
On a final note:
Their is one tool that could help you, I haven't used it, because it isn't for VSCode, it's for Visual Studio, but it might give you more control than you have now. The tool is called..."_
Text Sharp (Click Here to see it in the VS Market Place)
(Sorry for my poor English)
Yesterday, I encountered a problem when using #font-face with a really large font-size (200px): one of my div rendered differently in Firefox and Chrome. After doing some research, I learned that it was due to Firefox and Chrome calculated line-height differently, and a specified line-height could solve my problem.
BUT, to my suprise, even if I did nothing, when I start FF in safemode, the problem solves itself! (it renders similar to Chrome) So I wonder that's because I've customized FF too much? I creat a new profile (no addon, disable all plugin, reset all settings to default) but the newly created profile works the same like my old profile, and different with FF in safemode. I don't understand it?
Safe mode, in addition to turning off all add-ons, also turns off the JIT and hardware accelerated rendering.
And if you're on Windows (which I assume is the case given the described behavior), then turning off hardware-accelerated rendering also turns off DirectWrite rendering of text and uses GDI instead.
But DirectWrite and GDI end up with different font metrics for the same text: for one thing DirectWrite can do subpixel glyph positioning, and GDI cannot. So if you turn on safe mode, line heights and various other aspects of text layout can change.
Note that Chrome uses GDI to start with. IE 9 and 10 on the other hand, use DirectWrite, so it's worth testing how your page behaves in those; I'll bet it's similar to Firefox not in safe mode.
I have a large legacy application which is showing up with a perpetually grey border on every Windows 8 machine we run it on, while the other windows for other apps accurately use a color derived from the desktop background. For the life of me I can't find out why.
I've tried my best google-fu to crawl MSDN for APIs to control this but came up empty. The app looks like all others in Windows XP, Vista, and 7...just Windows 8 is grey in color. We definitely haven't added Win8 specific code to treat this otherwise.
It's just an MFC window on the outside, but inside it embeds a .NET/WPF component and a Direct3D 9-enabled visual area.
My best guess is it could somehow be related to having a Direct3D surface in the window, but I couldn't validate that anywhere.
Any help would be greatly appreciated!
Thanks
Edit: The grey matches the effect of not having focus, and we definitely do play games with window focus...so that could be it.
The problem was a developer overloaded OnNcActivate() and returned TRUE at the end. They needed to call up to the baseclass's (CWnd) OnNcActivate instead.
This was visible on Windows 7 as well if you looked close enough.
The Desktop in Windows 8 does not use transparency in window borders like Windows 7 and Vista did with the Aero Themes. If you are move the focus to another top window in your app, this could explain why your seeing the grey border. Try changing the colors for windows without the focus to something discernable from grey to verify that is what you are seeing.
I'm sure this has been discussed before, but I can't find any canonical question / answer.
Currently, IE9 and Firefox 4+ both use different font rendering that produces (for some) more blurry fonts but overall better kerning and more consistent results. Also, it renders non-standard fonts on Windows much better. I've have not done a thorough investigation, but I think it has to do with the fact that both IE9 and Firefox use now a different graphics layer which in apparently renders fonts differently. Also, the reason some of the standard fonts such as Arial, Tahoma etc. look in Firefox the same as 10 years ago is that it actually has a list of exceptions for them (look for gfx.font_rendering.cleartype_params.force_gdi_classic_for_families).
So far so good. The problem is Chrome. It still uses the old font rendering that makes the non-standard fonts practically unusable. Just for illustration, the font I had in mind was: http://www.google.com/webfonts/specimen/Play. Just open the sample in Firefox/IE9 and Chrome and you should see the difference. Is there anything I can do? Or should I look for a more optimized font.
Update: I see it's a common problem: the headings on http://www.smashingmagazine.com look very jaggy in Chrome.
Update: Sample image:
I have read that Chrome (originally Chromium) has anti-aliasing issues that's why it's jaggy.
Using font-faces also makes a difference than using local fonts in your system. So, all we can do is just wait until they fix this issue or help the Chromium Project if you can.
Known issue. You can try gdipp or MacType.
Copying my anwswer from Making CSS3 #font-face font rendering play nice with ClearType on Windows
A similar question here: Font-face embedded fonts look fuzzy in Windows 7 browsers got an answer that solved the same issue for me.
The fontsquirrel font generator http://www.fontsquirrel.com/fontface/generator optimizes fonts and adds them with hinting/rendering info that helps the windows font rendering engine render them better. It also generates smaller files, which will download faster.
Could someone go to this url: http://www.barbadostravelbuddy.co.uk/demo/?r=register
in IE8 and tell me what the submit on the bottom of the right hand column looks like, please?
I suspect my emulator isn't working correctly on this point of CSS.
It should have white text on a blue gradient but my emulator is showing with a white block. In IE7 (the real version) this does display correctly and it seems unlikely IE8 would regress.
IE8 result here :
http://img405.imageshack.us/img405/7784/screenie8.png
What emulator are you using? Would suggest you to use IETester. It uses the actual COM object of Trident (the Internet Explorer rendering engine) and hence seems quite reliable.