Shading rendering artefacts

[timvandermeij]

Tracking issue after #6304 landed:

• http://www.tcpdf.org/examples/example_030.pdf and https://issues.apache.org/jira/secure/attachment/12652089/CIB-coonsmesh.pdf render almost perfectly now, but still some white spots appear.
• http://tavmjong.free.fr/SVG/MESH/lamp_cairo.pdf is still broken, but @THausherr might have code to solve this (feel free to create a PR for that and if needed we can fix it up for you).
• https://github.com/mozilla/pdf.js/raw/master/test/pdfs/coons-allflags-withfunction.pdf renders better now and the artefacts are very likely to be related to already existing issues (#6294 and #6284).

[THausherr]

There are two kinds of problems, the "white spots" and the "extra side stuff".

The white spots in the middle for the CIB file are likely because the shadings are only approximated by the use of a triangle mesh for each type 6 (coons) patch. See here for an explanation by Shaola Ren who developed it as part of GSoC2014: https://issues.apache.org/jira/secure/attachment/12647265/patchMap.jpg I think that some "empty" surfaces remain when the curve isn't perfect.

PDFBox uses this method and it seems PDF.js does it too, based on some comments I've seen in the code. Here's a file with type 7 (tensor) that is rendered nicely with the released version (likely because only flag 0 is used), although with some white spots: http://kupmeyer.com/wp-content/uploads/2012/02/K_UPMEYER_SPRING10.pdf

I'll create a PR for tonight for type 7, however it doesn't solve the lamp_cairo.pdf file, but it solves another file I created. You can see that the current rendering has a similar problem than the CIB file before the change. I'll try to find a file that I didn't create myself and that renders fully nicely with the change to prove my point.

another: https://issues.apache.org/jira/secure/attachment/12648478/tensor4-nofunction.pdf

[THausherr]

This is an absolutely minimal example of type 4 (Gouraud) shading for debugging which I just created. It has a single triangle, RGB, and no function. But in rendering it shows a vertical line in the same color as one of the corners, it is outside of the triangle, and even outside of the bounds rectangle. If anybody wants to make slight changes for debugging, here's the postscript code, which can be converted to PDF with ghostscript:

300 600 translate

72 dup scale

/A [0 30 sqrt 2 div 1 sub] def
/B [ -2.5 -1 ] def
/C [ 2.5 -1 ] def

/ds1 [
  0 A aload pop 1 0 0
  0 B aload pop 0 1 0
  0 C aload pop 0 0 1 
] def

newpath
<<
  /ShadingType 4
  /ColorSpace /DeviceRGB
  /DataSource ds1
>>
shfill

stroke

Coons and Tensor patches are made of many triangles, so this could result in many "extra" lines like seen with the lamp_cairo.pdf file or my coons test file.

Another one for the list of artefacts http://www.math.ubc.ca/~cass/graphics/manual/pdf/ch14.pdf (p. 1, 13, 15, 20)

[THausherr]

I'll try to find a file that I didn't create myself and that renders fully nicely with the change to prove my point.

I searched on 250000 PDF files (the digitalcorpora files) and had about 50 files with ShadingType 7, but none with flags other than 0. The lamp_cairo.pdf file does also not use these flags. So PR #6310 will be visible only for the two test files mentioned.

[timvandermeij]

From the two bottom PDFs in https://github.com/mozilla/pdf.js/issues/6305#issuecomment-127496152 only very minor differences with rendering in Adobe Acrobat/Reader remain after #6310, but they are quite insignificant.

[MadeleineCodes]

Hi :) I know this a very old issue, but since we currently experience something very similar with some of the pdfs of a client, I just wanted to check if there are any plans to fix this in the near future? I could also provide a sample pdf if that helps!

Is there maybe something we could do to prevent this otherwise? I am absolutely no expert here, so maybe there is something that can be changed in pdf generation to prevent this from the beginning?

Thanks!