New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 113777 link

Starred by 89 users

Issue metadata

Status: Archived
Owner: ----
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment

GDI++ fail to work with Chrome 18+

Reported by, Feb 11 2012

Issue description

Chrome Version       : 19.0.1036.7
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:chromium 17.0.963.38
                      chrome Stable 17.0.963.46
                      chrome dev 18
Add OK or FAIL after other browsers where you have tested this issue:
    chromium 17.0.963.38:OK
    chrome Stable 17.0.963.46:OK
    chrome dev 18:FAIL

What steps will reproduce the problem?
Stop mactype or gdi++ working

What is the expected result?
Fine font glyphs rendering using GDI++ (or probably gdipp),including Chinese and English

What happens instead?
The menu and toolbox of Chrome is rendering correctly,but fronts of webpages is displaying in a weired way without correct rendering.  

Please provide any additional information below. Attach a screenshot if
NOTICE!!!This is one significant bug, esp for Asian users,because MICROSOFT did it with ugly cleartype on windows platform, now chrome devs stop working with gdi++,which greatly affected the experiences of Chrome for asian users.If the bug isn't fixed ,I'm afraid I have to switch to other browser instead.

UserAgentString: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.20 (KHTML, like Gecko) Chrome/19.0.1036.7 Safari/535.20

187 KB View Download
Labels: -Area-Undefined Area-WebKit WebKit-Fonts

Comment 2 by Deleted ...@, Feb 11 2012

I encountered the same problem

Comment 3 by Deleted ...@, Feb 11 2012

I hope google could solve this problem,i hate the ugly asian font render on windows of microsoft,plz think of our suggest,thx!

Comment 4 by Deleted ...@, Feb 11 2012

for the same reason, i downgrading the version to chrome17...

Comment 6 by Deleted ...@, Feb 11 2012

Plese solve it
Plese solve it.We are Asian!

Comment 8 by, Feb 11 2012

I have reinstalled version 17 : (

Comment 9 by Deleted ...@, Feb 11 2012

Not solve the long-term manned 17

Comment 10 by Deleted ...@, Feb 11 2012

Plese solve it.We are Asian!

Comment 11 by Deleted ...@, Feb 11 2012

beta 18 have same problem

Comment 12 by Deleted ...@, Feb 11 2012

also switched from beta to stable channel because of this. :(

Comment 13 by Deleted ...@, Feb 11 2012

when i need to browse the page in Mactype,I switch the browser to Firefox……but i love Chrome most.Please solve the problem~Thx~

Comment 14 by Deleted ...@, Feb 12 2012

Please solve this problem, or give a plan.No GDI++ and mactype font is so ugly .

Comment 15 by Deleted ...@, Feb 12 2012

Agreed. this is kind of a problem so annoying
same here

Comment 17 by Deleted ...@, Feb 13 2012

Plese solve it.

Comment 18 by Deleted ...@, Feb 17 2012

please solve it

Comment 19 by Deleted ...@, Feb 26 2012

please solve it

Comment 20 by, Mar 8 2012

I thought it's related to my local video driver or something.
I've been suffering from the same issue for several versions (in dev. channel)
As mentioned above, menu , UI fonts are ok, but the content rendering is not ok.
Please kindly take a look at it.

Comment 21 by, Mar 8 2012

Is there a simple URL that shows this, or reproduces the original attachment?

Comment 22 by, Mar 8 2012

I don't have my Windows with me now (home), let me get back to you tomorrow while I have a Windows system (office).
Thanks for you response.  

Comment 23 by, Mar 8 2012

The problem is reproducible if you install GDI++ or MacType and see it's effect.

It's nothing with video driver, just the rendering process of the browser. You see, before Chrome 18 it's okay but now it's broken. IIRC it happened at around build 100000.

Comment 24 by, Mar 8 2012

If GDI++ and Mactype are patching GDI, then we will need some insight into what they are patching, to try to understand what Chrome is doing that is somehow defeating those patches. Suggestions?

Comment 25 by, Mar 8 2012

Personally I don't use GDI++ so I can't say if it has the problem too (but likely).

However, GDI++ is open-sourced. It can be found here:

I can't read the code, but I'm sure somebody here can.

Comment 26 Deleted

Comment 27 by, Mar 9 2012

I dunno how to reproduce with a simple URL but I can show you by opening the same content in both Chrome and notepad. Rendering in notepad is ok but not so ok in Chrome.
Hope it helps.
Thank you.

235 KB View Download

Comment 28 Deleted

It returns to normal  in 18.0.1025.133 beta.
Now it works like a charm.  :)
It returns to normal  in 18.0.1025.133 beta.

Comment 31 by, Mar 23 2012

Why, dev channel 19.0.1068.1 dev-m is still not fixed. Is beta channel using new WebKit?
Maybe a temporary change?
It seems to be related to and (unfortunately I cannot see it).
Maybe ?

Comment 33 by, Mar 23 2012

So maybe it's SwiftShader which causes the font rendering process out of GDI's control? It was added to Chrome at version 18, about the time the problem took place.
Oops!!! It fails rendering again  in 18.0.1025.140 beta. The ugly fonts come back again :(
What is mactype?
Mactype is a font rendering software based on GDI++.  
Why using it ?
The font (especially CJK fonts )in windows will be more clear,smooth and beautiful.
What's the problem at present?
It doesn't work in chrome. Worse still, the CJK font(eg.chinese font) is too ugly to tolerate in chrome at present. IE 9 also has the same problem but chrome 17 and ie 7/8 works well.
Attach mactype installer for you to reproduce the bug.

2.9 MB Download
please, fix it!

i hate cleartype rendering...

Comment 36 Deleted

Comment 37 by Deleted ...@, Mar 29 2012

same here i am using 360 extreme nightly now

encounter the font problem. can't view web without mactype now

so hope it will be fix in the stable chrome browser
Can not even read the letter...X(

Chrome 18.0.1025.142 m stable
Enable GDI++
105 KB View Download

Comment 39 by Deleted ...@, Mar 30 2012

shit... pathetic chinese glyph without mactype

Comment 40 by Deleted ...@, Mar 30 2012

Labels: -Pri-2 Pri-1 GoogleFeedback Hotlist-Japan
Status: Assigned
reed@: I was able to confirm the issue. Just install gdipp from reboot and launch Chrome (any web page or internal page should exhibit the issue).

This is already in the TOP 10 of issues from Google Feedback for Japan and quickly climbing to the TOP 5.

I am also afraid that a significant part of our users might not understand what is going on, should we have a conflicts notification infobar while we find out if we can fix the issue without too much hassle?

gdipp is open source, you might be able to find out what's going on from there.
Parallel to that I will run a bisection to find out a bit more.

If you don't have enough bandwidth to work on this, let me know. Thanks.

Confirmed on Chrome 18.0.1025.142 m and Chrome 20.0.1088.0 canary on a Japanese Windows 7 64 bits.

reed@: you probably knew the results but just to be sure I ran a bisection:

You are probably looking for build 115314.
Built at revision:

Webkit changeset 103349 seems obvious:

What are our alternatives?
 * Find out how to avoid gdipp and the like to interfere
 * Find out how to let gdipp and the like take over the font rendering if we can detect it?

Comment 43 by, Apr 2 2012

too many URL, so what solution do u propose? which one to use?


你想获得 MindManager 视频教程吗?
点击下图注册 MindManager 电子报!

See also

Seeing that everything works with standard GDI, the issue seen here is most likely due to gdipp not completely emulating GDI.
Cc: suggests a workaround for GDIPP users; apparently editing a config file can turn off GDIPP for chrome?
 Issue 96662  has been merged into this issue.
The most obvious issue is one similar to

Skia relies on GetGlyphOutlineW for metrics. The current tip of tree gdipp does not hook this call, so Skia cannot reliably know what to expect. There is also a development branch of gdipp (which now appears to be closed) which does hook GetGlyphOutlineW (this is the branch patched in the above linked issue). However, the hook is only reliable on the identity transform. In order to achieve certain functionality, Skia almost never uses an identity transform with GDI. As a result, even gdipp 0.9.1 does not sufficiently implement GDI in order to support Skia.

Comment 48 by, Apr 4 2012

 Issue 121693  has been merged into this issue.

Comment 49 by, Apr 4 2012

Labels: -Type-Bug Type-Regression
Summary: REGRESSION: GDI++ or Mactype fail to work with Chrome 18

Comment 50 by, Apr 4 2012

Adding search keywords: heavy black line lines over above letter letters word words text

Comment 51 by Deleted ...@, Apr 4 2012

Same thing with 20.0.1090.0 canary and GDI++ 0.9.1 on Windows 7 Pro x84.
Please help!

Comment 52 by, Apr 4 2012

The developer of MacType is going to release a new version tomorrow, and it's said that that new version can correctly render texts in Chrome. However MacType is closed source so somebody have to try to persuade him to tell us what changes he had made (if we need to know that). Do we need to know that?
hm... interesting and promising comments. by the way, will (does) Chrome support MacType/GDI++ "injection" without the --no-sandbox launch key, or are there any other advanced ways to inject custom font-renderer?
mrx: yes, that could help.
Copy pasted comment #47 on gdipp's tracker.
If you are affected by this issue, please star this:
While GetGlyphOutlineW is an issue as stated above, it does not explain the ugliness of what is seen. As it turns out, the way Chrome uses Skia, Skia always asks for GDI to draw the text at a size of 64 and uses SetWorldTransform to scale to the appropriate size. What GDI does is hint at 64, apply the transform to the outline, and then rasterize. Gdipp, on the other hand, is rasterizing with freetype at a size of 64 and then using BitBlt from a temporary surface into the destination surface. BitBlt is not known for its rescaling ability, and this appears to be most of the issue. As an experiment I forced all text to 64 pixels and everything looks suprisingly good (though very large).

@53 scarshock: I have not looked into MacType, if it requires disabling the sandbox then I would recommend against it. Of course, I would recommend against any of these hooking services. Gdipp appears to have a somewhat sophisticated RPC system which allows it to hook Chrome even with the sandbox.
I have reached out to the owner of gdipp.
Will update him with the comment above.

Thanks for the deep dive.
Labels: -Pri-1 Pri-2
Owner: ----
Status: ExternalDependency
This doesn't seem like we can do something about from the Chromium side, right?

  Assigned => ExternalDependency
  Pri-1 => Pri-2

@bungeman, very interesting and insightful comment about how Skia and gdipp work to render fonts. Hopefully the author can use it to fix the issue.  Having a little bit (but not a lot) of spare time I checked out the gdipp 0.9.1 revision and changed all the BitBlt calls to StretchBlt and assuming the same size for the source and destination rectangles, but as you can imagine that didn't make much of a difference. :) 

Comment 60 by Deleted ...@, Apr 6 2012

Hello there, I'm the author of Mactype.
According to the webkit updates, Chrome begin to use internal bitmap bitblt to accelerate GDI text rendering, which makes shadow function of gdipp and mactype invalid. Moreover, chrome begin to use GDI coordinate transformation to draw GDI text, this is what causes gdipp render messed.
The new MacType now support render text on DCs which has transformation enabled, thus the chrome can be smoothed, see the attached figure.
You can test mactype from
159 KB View Download
Thanks for upgrade.
Thank you so much !!
awesome, thanks!
 Issue 121058  has been merged into this issue.

Comment 65 by, Apr 6 2012

Hey, it's looking good.
Thank you so much. 
223 KB View Download
Wow, thanks so much - MacType is wonderful! You have made a lot of people very happy with this change!

Comment 67 by Deleted ...@, Apr 7 2012

Now I'm very suspicious about that "Mactype" software after Norton found a virus from it. Be careful.

Comment 68 Deleted

pikkuallu94: where did you download it from?
FWIW, TrendMicro didn't find anything in the binary from

(That being said, be extra careful with whatever you install and always run your own antivirus scan)

pikkuallu94: Norton isn't known for its accurate results... I personally don't use antivirus at all, I just use my common sense. BTW, this is off-topic.
 Issue 122380  has been merged into this issue.

Comment 72 by Deleted ...@, Apr 11 2012

since mactype uses a lot of hook and tries to inject its dll to all the system processes, some anti-virus softwares may give false positive results. after some days, these files will be add to their databases and you won't see that again.

Comment 73 by Deleted ...@, Apr 14 2012

I use windows xp pro english sp3 32 bit, with all the latest updates. I have the same problem on every English, Spanish, Russian site etc and in Chrome own settings page!!! I tried to use stable version of Google Chrome 18.0.1025.162, 18.0.1025.152 and 18.0.1025.142. Please, fix this problem!!! I never install gdipp, gdi++ or mactype or something else. And I'm not Asian. I only use ClearType in Windows Desktop Properties. I can't turn off it, then windows will be ugly. Only version of Chrome stable 17.0.963.79 doesn't have this problem.

Comment 74 by Deleted ...@, Apr 16 2012

I installed Mactype and it looks great on chrome 19.0.1061.1  but that's how some bold fonts appear: 
this doesn't happen to firefox. only chrome. 
131 KB View Download

Comment 75 by, Apr 18 2012

Am using GDI+ and with version 18 upgrade, I am facing the same issue. Text is garbled like hell.

Comment 76 by Deleted ...@, Apr 19 2012

Come on Google, fix this, it has gone on for far too long..
Windows 7
chrome Stable 17.0.963.46:OK
chrome dev 18:FAIL
BBC News - Abu Qatada appeal- May stands by deadline.png
903 KB View Download
is that with mactype? mactype (latest version w/ default settings) + chrome 18 work great for me.  if you are still using gdipp, uninstall it and use mactype instead.

Comment 78 by Deleted ...@, Apr 24 2012

Windows 7 x64 SP1, Chrome 18.0.1025.162 m

Guys, this is your page! Do you have a QA staff there?
39.2 KB View Download
I have a font rendering problem with Chrome but which is also mirrored with IE, but NOT on Firefox, which renders just fine.   

This shows up with jagged fonts that look terrible (but are readable - it's not producing just garbage) although the page concerned looks fine in Win 7 on Win XP Pro SP3 - my machine (after downgrading following the Vista debacle when I swore not to go with any new MSFT O/S until they'd thoroughly worked through bugs & compatibility issues.. some of my specialist software won't run on Vista) 

I'm not a graphics/web/technical savvy guy, but am wondering if any of this is related to what's being discussed in this thread?

Other sites also render strangely, and I'd love to have Chrome & IE render fonts as nicely as Firefox does..  any suggestions please?   

Sample screen shots attached 1 - IE, 2 - Chrome, 3 - Firefox

Firefox capture.png
52.7 KB View Download
Chrome capture.png
47.0 KB View Download
IE capture.png
47.3 KB View Download
@ Simon Ken

You're seeing two things:

1) With FF and IE, you're seeing sub-optimal (IMO) text rendering via DirectWrite
2) With IE and Chrome, you're seeing Windows' native (DirectWrite or ClearType) inability to render Helvetica cleanly.

Mactype, GDIPP, GDI++, etc. fix #2 for non-DirectWrite text rendering (Mactype is the only one fully functioning with Chrome right now).  You can't fix #1 without turning off hardware acceleration in the browser.
Thank you for this Ray, I'll be looking into it shortly.   Much appreciated!

This was fixed once before.  Why has it been broken again!  ugh!

Comment 83 by Deleted ...@, Jun 29 2012

Hello guys! Im new to gdi++. I'm using it on a Win 7 x86 PC. Every thing is fine except the font rendering in Google Chrome browser(20.0). Webpages on chrome don't get rendered by gdi++. Is there any solution to my problem? If so, please help me out. Thanks in advance.

Comment 84 Deleted

@comment #83, there is nothing we can do from the Chrome side to fix the issue in gdi++/gdipp so here's what you can do:
 First, add your voice to by starring it

  - add Chrome to the exclusion list of GDIPP gdipp_setting.xml ("<process>chrome\.exe</process>" works here).
  - OR uninstall GDI++/GDIPP and use an alternative software (mactype is the only one we know of where the issue has been fixed;  LCD profile seems to be the nicest setting; Available at )

Comment 86 Deleted

Comment 87 by, Jul 15 2012

To all of you saying "uninstall this" and "install this" or any other combination of "you should do this" "or that"... understand that it's not about me, it's about my site's visitors who aren't going to do ANYTHING special to make my sites work like they do in other browsers. Text rendering looks fantastic in IE9, the latest Firefox, and Safari (Opera still has issues unfortunately).

Comment 88 by Deleted ...@, Jul 16 2012

Bold and italicized fonts look especially horrid, and I hesitate using them in my websites because of the way Chrome handles them.  Google, come on, it's time to fix this one.
Project Member

Comment 89 by, Mar 9 2013

Labels: -Type-Regression -Area-WebKit -WebKit-Fonts Cr-Content Type-Bug-Regression Cr-Content-Fonts

Comment 90 by Deleted ...@, Apr 4 2013

Need this fu*king fixed! CMON GOOGLE.
Labels: Restrict-AddIssueComment-EditIssue
Summary: GDI++ fail to work with Chrome 18+ (was: REGRESSION: GDI++ or Mactype fail to work with Chrome 18)
This bug is about an external dependency with a third party software called GDI++.

The issue can't be fixed from our side. If you care about it, star or switch to a compatible font rendering enhancer (e.g. Mactype).

If you have other fonts issues that have nothing to do with GDI++, please file a new bug. Thanks.

I am closing public commenting for this bug.
Project Member

Comment 92 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 93 by, Apr 6 2013

Labels: -Cr-Content-Fonts Cr-Blink-Fonts
Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.

Comment 96 by, Jan 20 2016

Status: Archived
We no longer support GDI for font rendering on windows.

Sign in to add a comment