Closed Bug 929451 Opened 6 years ago Closed 6 years ago

canvas toDataURL creates green Text when used on white text over transparent background. (linux only)


(Core :: Canvas: 2D, defect)

24 Branch
Not set





(Reporter: vondemleschker, Assigned: roc)


(Depends on 1 open bug)



(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 Iceweasel/24.0 (Beta/Release)
Build ID: 20130918225509

Steps to reproduce:

Create Canvas with white Text and use to DataURL.

<!DOCTYPE html>
<html lang=en>
	<meta charset=utf-8>
	<div id="canvasContainer"><canvas id="canvas" width="1000" height="500"></canvas></div>
            var textCanvas = document.createElement('canvas');
            var c = textCanvas.getContext('2d');
            c.font = "8pt sans-serif";
            c.textAlign = "center";
            c.textBaseline = "middle";
            c.fillStyle = "white";
            c.fillText("Test Text", textCanvas.width / 2, textCanvas.height / 2);
            var image = new Image();
            image.src = textCanvas.toDataURL();

Actual results:

The resulting DataURL on my machine is:


Which is a greenisch text.

Expected results:

The Image should be white Text with transparent background, as png is a lossless compression there should be no arthefacts.

This only happen under Linux. Windows-FF works well.
Component: Untriaged → Canvas: 2D
Product: Firefox → Core
Ever confirmed: true
Attached patch fix (obsolete) — Splinter Review
This should fix it.
Assignee: nobody → roc
Attachment #8356971 - Flags: review?(bas)
I can't reproduce locally, for some reason.
Comment on attachment 8356971 [details] [diff] [review]

Review of attachment 8356971 [details] [diff] [review]:

::: content/canvas/src/CanvasRenderingContext2D.cpp
@@ +918,5 @@
>      mTarget = sErrorTarget;
>    }
> +
> +  if (!mOpaque) {
> +    mTarget->SetPermitSubpixelAA(false);

Hrm, in theory for non-opaque surfaces not permitting subpixel AA should be the default. If it's not on Linux we should probably fix that too. Although for now I have no objections against this patch.
Attachment #8356971 - Flags: review?(bas) → review+
Well, let's fix it properly then.
Nasty low-level bug in the cairo FT code. This _cairo_ft_options_merge function looks quite wrong to me.
Attachment #8356971 - Attachment is obsolete: true
Attachment #8357710 - Flags: review?(karlt)
Yes, _cairo_ft_options_merge is quite wrong [1], but it is more complex than

The way cairo is usually used is as follows:

 cairo_ft_font_options_substitute to add surface (screen/print/etc) font
 options to an FcPattern.

 FcFontRenderPrepare is passed this pattern so that the font configuration
 system knows the target for rendering and can set font-specific options:
 e.g. select the hinting, antialiasing, and lcd filtering based on the target,
 quality of the font, slant, etc.

 cairo_ft_font_face_create_for_pattern sets up "other" options based on these

It is a bit awkward that the "options" from the scaled_font come from both the
target font_options as well as the gstate font_options from the client, but
usually these come from the surface.

So we have some contention over whether surface font options or fontconfig
preferences should win [1].

Things go more wrong here because the font_face was created for an RGB surface
but used on a grayscale surface.

The way to resolve this is to consider surface font options as indicating the
capabilities/limitations of the surface, and then accept user options that fit
within those capabilities.

Comment on attachment 8357710 [details] [diff] [review]
_cairo_ft_font_face_scaled_font_create should honor CAIRO_ANTIALIAS_GRAY set in the font options parameter

The screen font options may indicate that grayscale or rgb antialiasing be the
default or are available, but it is OK for the font-specific options to
override these and request no antialiasing.
Attachment #8357710 - Flags: review?(karlt) → review-
Still need to add testcase and add patch to gfx/cairo/README.
Attachment #8358264 - Flags: review?(roc)
Attachment #8358264 - Flags: review?(roc) → review+

Aa is disabled on Ubuntu 12.04 reftest machines, so this isn't really in-testsuite+ yet, but at least we have a test to run when we have aa.
Flags: in-testsuite+
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
It's really gone in FF29! :) 

Thanks for the work guys.
Depends on: 1072372
You need to log in before you can comment on or make changes to this bug.