Failure to do subpixel anti-aliasing

[gcp]

Continuation of #2349

https://www.schneier.com/paper-twofish-paper.pdf

On Windows 8.1, current Nightly (but note original report was on Windows 7), this PDF does not get subpixel/ClearType antialiasing, only greyscale antialiasing. This makes the PDF significantly harder to read with pdf.js compared to Adobe Reader.

Adobe vs pdf.js
https://dl.dropboxusercontent.com/u/32496746/pdfbadhint.png

Zoomed in view showing lack of subpixel AA:
https://dl.dropboxusercontent.com/u/32496746/pdfbadhint2.png

[gcp]

Another thing you can see in the screenshot is that Adobe snaps vertically to the pixel grid, and we don't. You can see it for example on the bottom of the first T, or the "block cipher" words. We just get a gray goo while they get a good letter outline.

[gcp]

Hmm, so interestingly it seems Adobe has their own font rasterizer that works differently from Windows & Mac OS X. Some details on how it works:
http://www.antigrain.com/research/font_rasterization/index.html#toc0005

That page seems to agree with the zoomed screenshots above.

[speedplane]

For me, subpixel font rendering does not work in the tracemonkey document example. In the image below, pdf.js renders the document on top and adobe renders it directly below. Notice that there are tiny artifacts in the pdf.js around the fonts (it's hard to tell because of image compression in the screenshot). This becomes more obvious when you zoom in (see image further down).

Zoomed In (pdf.js on top, adobe reader on bottom):

Notice how the image in adobe reader is not just black and white, but is also red and blue. That's the subpixel antialiasing, which makes documents much easier to read.

EDIT: I am using Chrome on Windows 7.

[yurydelendik]

@speedplane works for me, provide more information about your configuration (see CONTRIBUTING.md).

Also, if you are disabling web fonts, pdf.js does not use system's font rendering and trying to draw letters itself (please notice web page cannot tell anything about your LCD monitor configuration).

[yurydelendik]

@speedplane Looks like it's Chrome specific I can see it on Mac OSX as well:

See Firefox for comparison:

[speedplane]

So maybe it only works in Firefox? This is what it looks like in IE 9, also no subpixel antialiasing:

[yurydelendik]

@gcp @speedplane PDF.js is using HTML5 canvas fillText (which is at least on Firefox, uses system api). So "Failure to do subpixel anti-aliasing [with PDF.js]" is somewhat invalid statement, see my comment/picture above. Here is also screenshot from the linux http://i.imgur.com/GbxpviB.png . So I would guess it depends on the configuration and it is happening with regular HTML5/JavaScript canvas as well, not with just HTML5PDF.js. Let us start filling bugs for other browsers?

[speedplane]

Okay, done.

[yurydelendik]

Okay, done.

Bugs against PDF.js will not reach browsers vendors, please file upsteam bugs instead

[speedplane]

I see... I have no problem taking the time to do that, but I'm not quite sure what to say. Is the problem that HTML5 canvas fillText fails to do subpixel anti-aliasing?

[yurydelendik]

We need minimal test case to proof the above

[yurydelendik]

Test case http://jsbin.com/bolusaceyufo/1/ (https://gist.github.com/yurydelendik/bc5e8f03f768ca211adc)

[gcp]

There's nothing "invalid" about the report, it clearly states the operating system(s) and browsers on which the behavior is observed, the document used, and screenshots illustrating the failure.

Who's responsibility it is to render the fonts is something you can argue about, but the result is the same: pdf.js's performance in these conditions is considerably worse than its competition. Note also that as far as I can tell, that competition has chosen not to rely on platform or OS features to get it right (see my third comment).

[speedplane]

I'd also note that on Chrome the issue has been open for five years and no one from google has commented on it for more than two. So if we want this fixed, we may have to do it ourselves.
https://code.google.com/p/chromium/issues/detail?id=7508

[yurydelendik]

@gcp That's why PDF.js is trying to provide feedback for other browsers to make the product better and make HTML5 a valuable platform. We also exploring other means of display, e.g. SVG backend to work around problem like this. If browsers decide to expose LCD configuration, then we as "competitor" might choose to do the same as you mentioned in your comment above.

[gcp]

Is there a bug filed against Firefox to render HTML5 text properly or expose the LCD configuration?

[yurydelendik]

Is there a bug filed against Firefox to render HTML5 text properly or expose the LCD configuration?

Not that I know of. The project is community driven, so you are welcome to do so at https://bugzilla.mozilla.org/

The latter would probably need an owner -- person who is willing to invest his time in implementing of the font rasterizer. And that will work only for browsers that will decide to report LCD configuration.

[speedplane]

Yes, the latter seems like a lot of work, but could make rendering much more consistent. I wonder if some libraries (maybe this? http://typerendering.com/) can make it easier.

[Snuffleupagus]

Closing as fixed by PR #6551.