1072372 - Subpixel rendering with pdf.js broken since Firefox 29 / Linux amd64

Status: RESOLVED WORKSFORME

(Firefox :: PDF Viewer, defect, P3)

Description

[dr.a.rohde]

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

Comment 1

[dr.a.rohde]

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

Comment 2

[dr.a.rohde]

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.

Comment 3

[Loic]

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.

Comment 4

[dr.a.rohde]

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.

Comment 5

[Loic]

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. :)

Comment 6

[Karl Tomlinson (:karlt)]

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.

Comment 7

[Brendan Dahl [:bdahl]]

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.

Comment 8

[Clemens Eisserer]

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

Comment 9

[Liviu Cirdei]

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.

Comment 10

[Jonas Jenwald [:Snuffleupagus]]

(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.

Comment 11

[dr.a.rohde]

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).

Comment 12

[Clemens Eisserer]

> 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?

Comment 13

[dr.a.rohde]

> 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