Chrome: Unexpected black fill in PDFs generated by Prince XML

[jwal]

I'll let the attachments speak for themselves...

• The example.pdf that renders badly in Google Chrome.
  • Quick view using pdf.js
• A Google Chrome screenshot of the badly rendered file.
• A Mozilla Firefox screenshot showing the expected rendering of the file.
• The html source for the PDF that was fed into Prince XML.

Versions:

• pdf.js 4dd0e02
• Mozilla Firefox 16.0.2 (Ubuntu 12.10)
• Google Chrome 22.0.1229.94 (Ubuntu 12.10)
• Prince XML 8.1 rev 3

[yurydelendik]

Looks like it's an absence of the fillRule for the canvas. Long story short: Firefox has mozFillRule, other browsers are still thinking. Read more at:

• http://lists.w3.org/Archives/Public/public-whatwg-archive/2007May/0338.html
• http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jun/0123.html

An implementation/support without this attribute will not look pretty or fast.

[yurydelendik]

Small code to replicate the issue ( http://jsbin.com/ayoyej/1/edit ):

    ctx.rect(10, 10, 100, 40);
    ctx.rect(15, 15, 90, 30);
    ctx.mozFillRule = 'evenodd';
    ctx.fill();

[jwal]

Thanks for getting to the bottom of this so quickly. Out of interest, I had a go at working around this problem by generating slightly different PDFs. I have an example html file showing that something might be possible using Prince XML's --javascript option.

[yurydelendik]

Filed upsteam https://www.w3.org/Bugs/Public/show_bug.cgi?id=19932

[jwal]

I have a build of Chromium based on a modified WebKit that implements this feature. As stated, the operation was already available but just not exposed through the canvas.

jwal/webkit@6ec4200

That changeset exposes it. Note, for compatibility with pdf.js I named the attribute mozFillRule instead of the more conventional webkitFillRule!

After I have finished all testing, I will rework the patch and try to get it submitted to WebKit.

[jwal]

I have now renamed the new property on the canvas in Chromuim to webkitFillRule (from mozFillRule). Here are some new links:

• A patch to WebKit that adds the new property (see also WebKit bug 105508)
• A patch to pdf.js that allows use of the webkitFillRule property
• The example.pdf rendered using pdf.js with the above modification
• A zero-installation zip release of Chromium that was linked against the modified WebKit
• A screenshot of the example PDF rendering properly using the modified pdf.js the modified Chromium

I guess my next task is to get these patches accepted, with any suggested improvements applied.

[jwal]

My WebKit patch seems to have triggered a discussion on the webkit-dev mailing list with an update to the HTML5 specification.

[yurydelendik]

@jwal, thank you for doing that. We have similar discussion here at #2534. However I can accept #2487 first (when the last comment is addressed) -- the specification defines fillRule now. We can always change the code to make it work with eoFill later.

[jwal]

Well, the browser has been updated. Thanks to Rik. He has also provided a patched viewer that uses the new browser feature:

See it working here: http://jwal.github.io/pdf.js/pdf.js-cabanier/web/viewer.html?file=../../example.pdf

[gus2986]

Please help with more info about it, I am trying to install the patched pdf.js without results, could you please explain more how to use this patch? something like step by step for beginners. Thanks

[gus2986]

Well, I did the changes according Pull Request #3201: Adds fill('evenodd') as alternative for mozFillRule,,, question do I have to have webkit full pack at the server running PDF.js? any config necessary at webkit side? Thanks for the help.
If I cant solve this issue, I will pay support for a hand here, if somebody is able to help me for fix the PDF.js package at my server.

[gus2986]

Got it, I was complicating the solution, thanks for the help.

[brendandahl]

Fixed by above PR.