User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 Build ID: 20140825054619 Steps to reproduce: Open a pdf file using pdf.js plugin (comes with firefox) such as this http://mozilla.github.io/pdf.js/web/viewer.html The problem is found in firefox 29 and up to 32.0.1 (official builds for Linux/amd64). A change request was raised against pdf.js as documented here https://github.com/mozilla/pdf.js/issues/4252 The issue was identified to be caused by firefox, not pdf.js Actual results: Since Firefox 29 and up to 32.0.1 the text of the pdf document is rendered using grey-scale antialising. Expected results: The text in the pdf document should be rendered using sub-pixel antialiasing as for the text in web pages or pull-down menus, dialog boxes, etc., as configured in the font sub-system (freetype/fonts.conf). The problem does not exist in firefox 24.8.0 ESR release. Attached are two screen shots. firefox24.8.0_ESR.png shows proper sub-pixel rendering. firefox32.0.1.png shows

I can't see whether the attaching the two .png files worked. You can see basically the same problem here: https://camo.githubusercontent.com/b01b91c669da15185c47485b4bdc4c06b787d08d/687474703a2f2f692e696d6775722e636f6d2f4d4f75715662422e706e67 https://github.com/mozilla/pdf.js/issues/4252

Correction of typo in last line of User Story: firefox32.0.1.png shows blurry greyscale antialiasing Please note the subpixel rendering feature with firefox/pdf.js is the main reason for me (and perhaps others ) to use firefox/pdf.js. Both the Adobe Reader and the Foxit Reader which support sub-pixel anti-aliasing are no more supported for Linux (or other Unixes) and should no more be used for security reasons. All other PDF Viewers under Linux (or other Unixes) such as okular (KDE), evince (Gnome) and xpdf - just to name a few - perform blurry, eye-straining greyscale antialiasing.

Could you run the tool mozregression to find the regression range, please. http://mozilla.github.io/mozregression/ FF29 nightlies started at the end of 2013, so --good=2013-11-01 is a good start.

Hi Loic, the issue was introduced in build 2014-01-30 2014-01-29 good 2014-01-30 bad Part of the console log below: Running nightly for 2014-01-26 Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/01/2014-01-26-03-02-03-mozilla-central/firefox-29.0a1.en-US.linux-x86_64.tar.bz2 ===== Downloaded 100% ===== Installing nightly Starting nightly (revision: 611698b4a246) Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): (process:3346): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed good Running nightly for 2014-01-29 Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/01/2014-01-29-03-06-02-mozilla-central/firefox-29.0a1.en-US.linux-x86_64.tar.bz2 ===== Downloaded 100% ===== Installing nightly Starting nightly (revision: 7e79536aca0a) Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): (process:3404): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed good Running nightly for 2014-01-30 Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/01/2014-01-30-03-02-02-mozilla-central/firefox-29.0a1.en-US.linux-x86_64.tar.bz2 ===== Downloaded 100% ===== Installing nightly Starting nightly (revision: 73eefb421e2a) Was this nightly build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): (process:3463): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed bad Got as far as we can go bisecting nightlies... Ensuring we have enough metadata to get a pushlog... Last good revision: 7e79536aca0a (2014-01-29) First bad revision: 73eefb421e2a (2014-01-30) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7e79536aca0a&tochange=73eefb421e2a ... attempting to bisect inbound builds (starting from previous week, to make sure no inbound revision is missed) Getting http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/01/2014-01-22-03-05-21-mozilla-central/firefox-29.0a1.en-US.linux-x86_64.txt Getting inbound builds between 8f4ecbf938cd and 73eefb421e2a Oh noes, no (more) inbound revisions :( do you want to bisect further by fetching the repository and building? (y or n) I don't have the build environment for gtk etc. installed so I stop here.

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7e79536aca0a&tochange=73eefb421e2a Suspected bug: Karl Tomlinson — b=929451 don't use subpixel aa for ft fonts on surfaces that don't support it r=roc Also: * Prefer subpixel order provided by the surface over that from the font face. * Allow font face options to turn off subpixel aa. CC'ing Karl to have his opinion. NB: To reporter, the last ESR is 31, ESR 24 is outdated now. :)

I assume the change in bug 929451 was the cause of the change, but that change was just making cairo do what Gecko was requesting. I suspect the core issue is that Gecko requests that RGB antialiasing is disabled when rendering text to potentially translucent surfaces. Note that https://github.com/mozilla/pdf.js/issues/4252 was reported on Win 8, and so this is not specific to Linux (even though the change for bug 929451 was). However, there are varying reports re Firefox behavior on that issue. It should be possible to use a blend mode that would use RGB AA when rendering to translucent surfaces that have been filled with alpha = 1, and perhaps some platforms support that, leading to the varying reports. If the canvas need not be transparent, then it should be possible to work around this with canvas.getContext("2d", { alpha: false }) but I'm not finding documentation on that and I'm not sure how well that interacts with the -moz-opaque attribute (bug 878149) on the canvas element. It may be necessary to set that attribute.

We currently set mozOpaque on pages where it is acceptable(e.g. no blend modes used). For reference mozOpaque became {alpha: false} when it was proposed as a standard see https://wiki.whatwg.org/wiki/CanvasOpaque.

I can reproduce it on Firefox 34.0.5, causes documents to be much less readable compared to Acrobat-Reader 9.

User Agent Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID 20160323030400 I tested this on the latest Firefox release (v. 45) and latest Nightly build (48.0a1) using http://mozilla.github.io/pdf.js/web/viewer.html page and I can't reproduce the issue. Can anyone else reproduce this issue on a current Firefox version? If not we should close the bug as WFM.

(In reply to Liviu Cirdei [:liviucirdei] from comment #9) > Can anyone else reproduce this issue on a current Firefox version? If not we > should close the bug as WFM. If it's indeed working now, it's probably better to instead mark this as a DUPLICATE of bug 1161147.

Hi Liviu and Jonas, I'm am the originator of the ticket and can confirm that this issue does no more exist in Firefox 45. To make my statement more precise: it works, if blending modes are not in use. Since none of the underlying graphics libraries for Unix/X11 is currently capable of subpixel rendering for fonts AND blending, this is as good as it can become. There *was* a test document for blending modes by Adobe http://acroeng.adobe.com/Test_Files/images/transparency/rgbrasterobjecttypes_109.pdf I have a local copy of it and only in this document subpixel rendering is disabled because it would break blending. Adobe Reader 9.5.5 (the last release for Linux) works exactly the same way (and performs blending partially incorrectly).

> Since none of the underlying graphics libraries for Unix/X11 is currently > capable of subpixel rendering for fonts AND blending, this is as good as it can become. With OpenGL shaders this should work out quite well?

> With OpenGL shaders this should work out quite well? Hi Clemens, I'm talking about libpixman and Cairo. I patched poppler to use subpixel antialiasing. My prototype uses the Cairo/pixman backend and is usable from okular, evince/atril, and qpdfview. It works only with an opaque background, either from the pdf file or by "painting" it using cairo calls. Painting it breaks PDF Blending Modes. I don't know about OpenGL shader capabilities. Did firefox switch to OpenGl recently? And if yes, does that explain that this issue (1072372) went away as an unintended side effect? Best regards, Axel