Previously we were filtering out non-scalable fonts /after/ the fact.
This patch changes it so that we specify to fontconfig that it
shouldn't return non-scalable fonts to us.
We also duplicate this code into WebFontInfo so that we don't get
these issues when performing glyph-fallback.
http://codereview.chromium.org/149437
BUG=16403
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20351 0039d316-1c4b-4281-b951-d872f2087c98
BUG=16047
TEST=Go to a site that has css with font-family: sans on Debian Lenny.
Review URL: http://codereview.chromium.org/149292
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20123 0039d316-1c4b-4281-b951-d872f2087c98
one in which isNull() returns true.
This assertion was being tripped as a result of some
recent changes I made to expose a CGImageRef as the basis
or a WebKit::WebImage. I think it makes sense to put
this null check in CGImageToSkBitmap instead of at each
callsite.
TEST=covered by mac ui tests
BUG=none
TBR=mark
Review URL: http://codereview.chromium.org/149173
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19900 0039d316-1c4b-4281-b951-d872f2087c98
This enables the ImageOperations.* and SkiaUtils.* test_shell_tests
on linux and mac.
Review URL: http://codereview.chromium.org/151097
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19701 0039d316-1c4b-4281-b951-d872f2087c98
If we ask fontconfig for an italic font, it might take a roman font
and set the undocumented property FC_MATRIX to a skew matrix. It'll
then say that the font is italic or oblique. So, if we see a matrix,
we don't believe that it's italic.
BUG=15212
http://codereview.chromium.org/147108
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19184 0039d316-1c4b-4281-b951-d872f2087c98
Before this patch we assumed that the style which we got from
fontconfig was the one that we asked for. Rather than do this we need
to query the resulting style and plumb that back into WebKit. Once
WebKit knows that there's a mismatch between the request and actual
styles it can trigger faking.
BUG=14810
http://codereview.chromium.org/147005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19095 0039d316-1c4b-4281-b951-d872f2087c98
I'll be needing in some pending WebKit changes.
http://codereview.chromium.org/131006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18676 0039d316-1c4b-4281-b951-d872f2087c98
on the screen again. Regressed in r18363.
Review URL: http://codereview.chromium.org/126140
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18415 0039d316-1c4b-4281-b951-d872f2087c98
(These were a merge artifact from r18405 which additionally broke the build on
GCC 4.4).
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18413 0039d316-1c4b-4281-b951-d872f2087c98
I had a typo in r18405 which meant that italic text wasn't actually
italic. This broke, ah, 'several' layout tests.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18411 0039d316-1c4b-4281-b951-d872f2087c98
http://code.google.com/p/chromium/wiki/LinuxSandboxIPC
Without filesystem access from the renderers, we need another way of
dealing with fontconfig and font loading.
This add support for:
* An "SBX_D" environment variable in the renderers which is used to
signal the end of dynamic linking so that the chroot can be
enforced.
* A sandbox_host process, running outside the sandbox, to deal with
fontconfig requests from the renderers. See the wiki page for
the reasoning behind making it a separate process.
* A new, custom SkFontHost for Skia. Because this is Chrome
specific, it will live outside the upstream Skia tree. This
FontHost can be configured either to drive fontconfig directly
(for the browser process and for any unsandboxed renderers) or to
use an IPC system. Since the same SkFontHost has to be linked into
both the browser and renderer (they are the same binary), this
switch has to be made at run time.
Sandbox IPC calls are rare (a couple of dozen at page load time) and
add about 50us of overhead for each call.
(Reland of r17575 which was reverted in r17577)
http://codereview.chromium.org/112074
BUG=8081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18405 0039d316-1c4b-4281-b951-d872f2087c98
Previously we had three classes of PlatformCanvas*, one for each platform. Then
we had a typedef of PlatformContext to PlatformCanvas[Mac|Win|Linux] for the
specific platform.
This means that it was almost impossible to forward-declare PlatformCanvas and
there were a bunch of unnecessary includes of platform_canvas.h in header
files.
This change makes there be only one platform_canvas.h header with ifdefs, which
removes a decent amount of duplicated code. There is a platform-independent
file, and one platform-dependent file of platform_canvas for each platform.
I also renamed PlatformDevice[Mac|Win|Linux] to PlatformDevice, althouth in
this case I kept the separate headers since there was much less overlap.
I also broke out CanvasPaint into separate headers so this template doesn't
need to be included all over the project (only a couple of files actually need
it).
Review URL: http://codereview.chromium.org/125109
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18363 0039d316-1c4b-4281-b951-d872f2087c98
BUG=8381
TEST=Open bookmark bar (Cmd-B). Add some bookmarks with sites that
have favicons (cnn.com). See icons in bookmark buttons. Make sure
color is correct.
Review URL: http://codereview.chromium.org/125061
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18340 0039d316-1c4b-4281-b951-d872f2087c98
just return null
Also remove unused GetLastError() call; no error is being returned anyway.
R=brettw
BUG=http://crbug.com/10977
TEST=none
Original review: http://codereview.chromium.org/120006
Patch by dpranke@chromium.org
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18195 0039d316-1c4b-4281-b951-d872f2087c98
This change exposed a deficiency in the XBM testing where we were erroneously using a zero-length set of image data to calculate the MD5 sum (because we were using the buffer rect instead of the image size, and the XBM decoder wasn't correctly setting the rect). Fixed the test to use the image size (which is more correct for this application), will fix the XBM decoder upstream to set the rect correctly.
This in turn required generating new MD5 sums, which required patching the generation code (which is normally #ifdefed away) to also work with the past couple years of changes.
This commit will need to land at the same time as one that updates the expected sums; during the period where either commit is in place without the other, the XBM decoding tests will fail.
BUG=13633
TEST=Covered by unittests
Review URL: http://codereview.chromium.org/121001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18131 0039d316-1c4b-4281-b951-d872f2087c98
function, which has no config, and the assertion fails. I just removed the
assretion, we assume ARGB8888 everywhere.
Review URL: http://codereview.chromium.org/118456
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17976 0039d316-1c4b-4281-b951-d872f2087c98
BUG=12762
TEST=Verify that buttons can be themed.
Review URL: http://codereview.chromium.org/119025
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17586 0039d316-1c4b-4281-b951-d872f2087c98
http://code.google.com/p/chromium/wiki/LinuxSandboxIPC
Without filesystem access from the renderers, we need another way of
dealing with fontconfig and font loading.
This add support for:
* An "SBX_D" environment variable in the renderers which is used to
signal the end of dynamic linking so that the chroot can be
enforced.
* A sandbox_host process, running outside the sandbox, to deal with
fontconfig requests from the renderers. See the wiki page for
the reasoning behind making it a separate process.
* A new, custom SkFontHost for Skia. Because this is Chrome
specific, it will live outside the upstream Skia tree. This
FontHost can be configured either to drive fontconfig directly
(for the browser process and for any unsandboxed renderers) or to
use an IPC system. Since the same SkFontHost has to be linked into
both the browser and renderer (they are the same binary), this
switch has to be made at run time.
Sandbox IPC calls are rare (a couple of dozen at page load time) and
add about 50us of overhead for each call.
http://codereview.chromium.org/112074
BUG=8081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17575 0039d316-1c4b-4281-b951-d872f2087c98
and font stuff for Linux. Rebaselines affected tests, adjusts
test_expectations, and removes an extraneous include dir. (Also sets the
svn:mime-type prop on some of the linux PNG files; they still diff as text
in rietveld this time, but I think they should be happier for next time.)
BUG=http://crbug.com/12002
TEST=If it builds, and layout tests pass, you're happy.
Review URL: http://codereview.chromium.org/118128
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17434 0039d316-1c4b-4281-b951-d872f2087c98
performance problems, so it would be nice to see what average users are seeing.
Review URL: http://codereview.chromium.org/113604
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16486 0039d316-1c4b-4281-b951-d872f2087c98
placed in third_party. All relevant skia changes (for all 3 platforms) have
been upstreamed.
Most of this CL is mind-numbingly repetitive. Things of interest are: skia.gyp
(now points at third_party versions), DEPS, and SkUserConfig.h. stdint.h: Skia
now requires C99 integer types, which MSVC doesn't support natively. I have put
typedefs in config/win/stdint.h.
Note that the new version of skia appears to render rects whose coordinates
are "backwards" (ie., x2 < x1 or y2 < y1), which were formerly culled. There
were a couple obvious instances of this in the code which I fixed, but there may
be more.
There were ~35 layout test failures due to minor pixel differences which I
rebaselined on Windows and Linux, and 8 genuine failures related to masks and
stroked text, which I have put in text_expectations.txt and assigned to
myself. (There was another change which broke ~1700 tests on each platform,
but I put that change behind an #ifdef for now).
R=brettw
Review URL: http://codereview.chromium.org/65012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15949 0039d316-1c4b-4281-b951-d872f2087c98