Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Chrome: Unexpected black fill in PDFs generated by Prince XML #2351

Closed
jwal opened this Issue · 13 comments

4 participants

@jwal

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

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
Owner

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:

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

@yurydelendik
Owner

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.

@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 jwal referenced this issue from a commit in jwal/pdf.js
@jwal jwal Added example PDF for Issue #2351 709b7e9
@jwal

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

@yurydelendik
Owner

@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
Owner

Fixed by above PR.

@brendandahl brendandahl closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.