Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 19 users
Status: Fixed
Closed: Sep 2014
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression

Sign in to add a comment
Vista fonts rendered using scaled embedded bitmaps at some sizes
Reported by, Aug 27 2014 Back to list
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Go to
2. Type the following in the HTML section:
<p>Is this text legible?</p>

3. type the following in the CSS section:
p {
  font-family: Calibri;
  font-size: 80%;

4. Look at the text below.

Note: When you change the font-size: 80% property to 70% the text does become legible!

What is the expected behavior?
Readable (but small) text.

What went wrong?
The text is not readable, because parts of the letters are missing. Maybe a but in the antialiassing of the letters when scaling in percentages?

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Previous stable release of chrome 36.

Does this work in other browsers? Yes 

Chrome version: 37.0.2062.94  Channel: stable
OS Version: Ubuntu 14.04.1
Flash Version: Shockwave Flash 14.0 r0

Please fix it, because i can't read my webmail properly... Aparently this 'font-size: 80%;' setting is used in all mail applications or outlook templates...
Screenshot from 2014-08-27 13:20:22.png
59.2 KB View Download
Can't reproduce on the exact same OS (Ubuntu 14.04.1) and Chrome version.
I don't have Calibri installed. Is there any other font which causes the same problem?
Comment 2 by, Aug 28 2014
I made a new codepen which three fonts with rendering issues. These are Calibri, Cambria and Courier New.
They are all Microsoft fonts which came with the installation of Office under wine.

I've created another codepen which shows that the bug appears only on certain percentages.

Screenshot from 2014-08-28 10:14:21.png
334 KB View Download
Mergedinto: 395528
Status: Duplicate
Comment 5 by, Aug 28 2014
Status: Available
I don't see any connection between this and anything that was discussed in  issue 395528 .

sansems@, check /etc/fonts and ~/.fonts.conf. I suspect that Fontconfig is configured to disable antialiasing at certain sizes. Deleting those stanzas will probably fix this.
Comment 6 by, Aug 28 2014
Status: Unconfirmed
Comment 7 by, Aug 28 2014
Thanks for the hint Derat, 

I went through all the config files in /etc/fonts and ~/.fonts.conf and did not find any reference to one of the three fonts that are not rendering properly.

What would a stanza to disable antialiasing for specific sizes look like? Maybe i wasn't scanning the content of the files properly.
Comment 8 by, Aug 28 2014
If you attach your ~/.fonts.conf and a tarball of /etc/fonts I'd be happy to take a look, but it's probably something like what's described at

Fontconfig is (perhaps unfortunately) very flexible, though, so it's possible that it looks entirely different. :-(
Comment 9 Deleted
Comment 10 by, Aug 28 2014
Ok, here is the following:

1) a zip of my /etc/fonts/ directory
2) a copy of my ~/.fonts.conf file
3) a zip of the referenced ~/.config/font-manager/ directory 

(i installed font-config in the morning to uninstall the 'offending fonts', the bug already had manifested itself.)
807 bytes Download
781 bytes Download
63.6 KB Download
Comment 11 by, Aug 28 2014
Hmm, I don't see anything that'd be disabling antialiasing at certain sizes in those files either. Just to double-check: do you have a ~/.config/fontconfig or ~/.fonts.conf.d directory? /etc/fonts/conf.d/50-user.conf includes those, so I suppose something could be hiding out there...

Do you still see the problem after adding the following between the <fontconfig> tags in ~/.fonts.conf?

  <match target="font">
    <edit name="antialias" mode="assign"><bool>true</bool></edit>
    <edit name="hinting" mode="assign"><bool>true</bool></edit>
    <edit name="hintstyle" mode="assign"><const>hintslight</const></edit>
    <edit name="rgba" mode="assign"><const>rgb</const></edit>

(Note that you'll need to restart Chrome after making Fontconfig changes.)
I can confirm that this issue also affects my Chrome 37 on Ubuntu 14.04.
This happens only for certain fonts (like Calibri) and certain sizes so when I change the zoom level of the page in Chrome the fonts become readable again.
(This did not happen in Chrome 36 so the regression may have something to do with the new update)
Comment 13 by, Aug 29 2014
Hi Derat,

I have a ~/.config/fontconfig directory which contains a font.conf file. This file only has the following include tags:
  <include ignore_missing="yes">/home/sansems/.config/font-manager/conf.d</include>
  <include ignore_missing="yes">/home/sansems/.config/font-manager/directories.conf</include>
  <include ignore_missing="yes">/home/sansems/.config/font-manager/local.conf</include>
  <include ignore_missing="yes">/home/sansems/.config/font-manager/select.conf</include>

Neither of the included files exists.


I've added the piece of xml to the ~/.config/fontconfig/fonts.conf file and rebooted my machine (just to be sure nothing was cached) It did not help, the fonts still rendered poorly under specific sizes. As indicated by 

Then i tried to do the opposite to verify that the settings are read and used so i modified the xml to the following and restarted chrome.

	<match target="font">
    	<edit name="antialias" mode="assign"><bool>false</bool></edit>
    	<edit name="hinting" mode="assign"><bool>false</bool></edit>
    	<edit name="hintstyle" mode="assign"><const>hintslight</const></edit>
    	<edit name="rgba" mode="assign"><const>rgb</const></edit>

I can confirm that these settings make things much worse. So the issue must be somewhere else. As Amir points out scaling the page by zooming in or out has influence on this. So when looking at with zoom 100%, the lines with 72% - 84% and 92%-99% scaling (for Cambria) render poorly. Zooming to 110% makes lines with 66%-76% and 83%-96% ugly. Note that not all lines have antialiasing but are legible.
Comment 14 by, Aug 29 2014
Adding a few Blink font-rendering wizards. Any ideas why we'd be using weird font-rendering settings at certain size ranges (see the screenshot in #2)? I can't think of anything besides Fontconfig, but I don't see anything to suggest that that's the cause here.
Comment 15 by, Aug 29 2014
And just to mention it: I don't see this with 37.0.2062.94, so I suspect it's still something related to local configuration.
115 KB View Download
Comment 16 by, Aug 29 2014
I'm getting the exact same thing, latest Kubuntu 14.04. I did notice the same when Chrome 37 was in beta so I rolled back to 37 is stable and once again it becomes hard to read Gmail with the zoom at 100%
Comment 17 by, Aug 29 2014
Looks like we're picking the embedded bitmaps at those sizes and try to scale those with disastrous results.
Derat: The leftmost font on your screenshot looks like it's the wrong font anyway, so I'm not surprised that you don't see it.

I'm seeing the same thing, with the same version. As a stop-gap, I'm adapting the fix suggested here:

It replaces the font, so it's not an ideal solution, but at least it lets me read Outlook emails from Gmail.
Comment 19 by, Aug 29 2014
Status: Untriaged
I was doubtful that Calibri would ship with embedded bitmaps, being a relatively-recent Vista font, but suggests that it does. And yeah, I see the problem as well at after installing the Vista fonts locally. :-/

Does adding the following between the <fontconfig> tags in ~/.fonts.conf work as a stopgap measure?

<match target="font" >
  <edit name="embeddedbitmap" mode="assign"><bool>false</bool></edit>

(It does here.)

Emil suggested that we should perhaps blacklist bitmaps for a few fonts. I'm inclined to agree.
Derat: Fix works here.
Comment 21 by, Aug 29 2014
Summary: Vista fonts rendered using scaled embedded bitmaps at some sizes (was: Text / font rendering not working properly)
P.S.: Thanks!
Comment 23 by, Aug 29 2014
@Derat, your fix works here too. Thanks!
Comment 24 by, Aug 29 2014
Yes! The fix works and makes the fonts readable again!

I'm not sure about the widths of some of these sizes. I was under the impression that the width should scale shoothly, but it seems to step for the sizes that were originally bitmapped.

So i consider this a proper workaround!

Thanks for all the hard work.
Comment 25 by, Aug 29 2014
Here's some more discussion:

An ancient Ubuntu bug about updating Fontconfig's default settings to disable embedded bitmaps (probably not happening anytime soon):

A thread claiming that these fonts include embedded bitmaps to handle the no-AA, no-ClearType case and stating that Windows only uses embedded bitmaps when ClearType is disabled:

I'll assert the following:

a) We definitely don't want to scale embedded bitmaps. (I hope that this isn't controversial.)

b) If we always use (unscaled) embedded bitmaps for Calibri and Cambria, we'll still get a bunch of complaints from users who expect antialiasing.

c) If we never use (unscaled) embedded bitmaps for Calibri and Cambria, we'll probably get a small number of complaints from users who have antialiasing disabled.

I was going to suggest the following: add a hack (maybe to FontRenderParams?) such that we force embedded bitmaps to be disabled for Calibri and Cambria when antialiasing is enabled.

But when I try that (and disable full hinting so we'll use subpixel positioning), while I don't end up with ugly scaled bitmaps, I too see a stairstep effect over the range where we were previously using bitmaps. I'm not sure why we seem to not be using subpixel positioning then.

(Cambria is bold in the attached screenshot since the cab file that I downloaded seemed to lack the regular version.)

I've uploaded my patch to in case anyone wants to play around with it.
302 KB View Download
Comment 26 by, Aug 29 2014
(It's also weird that Courier New isn't using subpixel positioning in my screenshot, and additionally in #2. It's not using full hinting, so I'm not sure what's going on there.)
Comment 27 by, Aug 31 2014
Just to make life easier for those who don't know which parts of the fonts.conf to kick or add, here is the correct fonts.conf (I checked it on different screens and different resolutions).

Credits for derat for finding the issue.

We need to figure out why that's happening.
Same issue on Fedora 20 with Google Chrome 37 Version 37.0.2062.120 (64-bit).

Adding those lines to ~/.fonts.conf from comment #19 fixed the issue for me.

However, previous versions of Google Chrome rendered all fonts perfectly on the same system without having to tweak ~/.fonts.conf.
I don't have a ~/.fonts.conf,  ~/.config/fontconfig or ~/.fonts.conf.d and I have this related issue:

I use Google Chrome 37.0.2062.120 (64-bit) on a Linux Mint 16 Petra (3.11.0-12-generic) system.
Ok, creating a ~/.fonts.conf with the content stated above:

<match target="font" >
  <edit name="embeddedbitmap" mode="assign"><bool>false</bool></edit>

works fine. Thanks!
Comment 32 by, Sep 19 2014
Status: Started
Sent for review so people won't need to add random cruft to Fontconfig to avoid this.
Comment 33 by, Sep 22 2014
Labels: -Type-Bug Type-Bug-Regression M-39
Ben said that he's planning to try to track down the root cause of this.
Project Member Comment 34 by, Sep 22 2014
The following revision refers to this bug:

commit a85511adc0173bd44ec18dd7f026ef191b2d683e
Author: bungeman <>
Date: Mon Sep 22 12:24:41 2014 -0700

Don't try to scale embedded bitmaps.

If a font is bitmap only we need to scale a bitmap to obtain
the requested size if there isn't an exact match. If a font has
embedded bitmaps then these bitmaps should never be scaled by Skia.
Allow FreeType to do the scaling (as requested by the font).

BUG= chromium:408059


Review URL:


There are two separate issues here. The change in comment #34 prevents trying to scale embedded bitmaps. This regressed when making changes to support color bitmap fonts and bitmap only fonts in general. After this change at least the text can be read.

The second issue is one that can only really be fixed by FreeType. I believe these fonts are set up in such a way that when using mono or grayscale anti-aliasing one should get the bitmaps, but when doing subpixel anti-aliasing newer style hinting should take precedence. This sort of change is something which Infinality has been working on for some time in FreeType, but I'm not sure what the current status is.

For the moment it's somewhat up to Chromium/Blink to decide when to use the embeddedBitmap flag. It may make sense to turn it off when asking for subpixel anti-aliased glyphs. Or it may make sense to have FontConfig .conf writers handle it.
Comment 36 by, Sep 22 2014
Thanks! Sadly, even when subpixel antialiasing is requested, I think that embedded bitmaps are often desirable for CJK fonts that are rendered at small sizes, so we probably wouldn't want to disable them across the board.

I didn't hear anyone complaining about embedded bitmaps in Vista fonts before the Skia regression that resulted in the bitmaps getting scaled, so I think it's fine to mark this fixed -- if someone really doesn't want to see the (unscaled) embedded bitmaps, they can disable them via Fontconfig.
Status: Fixed
Marking as fixed now that I've actually seen legible glyphs in Chromium with this change.
Comment 38 by Deleted ...@, Oct 16 2014
I had the same problem and it got fixed with the above suggested change in the fonts.conf file. At least it is readable, although the fonts don't look like before.
I have this problem on a Windows Vista desktop.  The .fonts.conf solution does not work there.  Suggestions?
Comment 40 by, Mar 27 2015
#39: This is a Linux bug, but suggests that on Windows, changing the ClearType setting might help (along with possibly making other changes that you may not want). If you're only seeing the issue on Chromium, please file a separate Windows-specific bug about it.
Comment 41 by, Jun 13 2015
Comment 42 by, Jun 13 2015
Attempting to remove from cc.
Labels: -Cr-Content Cr-Blink
Sign in to add a comment