Bug 705225 - Gradients not rendered with the new PDF interpreter
Summary: Gradients not rendered with the new PDF interpreter
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: 9.56.1
Hardware: PC Linux
: P4 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-04-15 13:43 UTC by Guillaume Ayoub
Modified: 2022-05-19 16:14 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
Sample 1 (4.26 KB, application/pdf)
2022-04-15 13:43 UTC, Guillaume Ayoub
Details
Sample 2 (2.66 KB, application/pdf)
2022-04-15 13:43 UTC, Guillaume Ayoub
Details
Sample 3 (1.62 KB, application/pdf)
2022-04-15 13:44 UTC, Guillaume Ayoub
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Ayoub 2022-04-15 13:43:10 UTC
Created attachment 22409 [details]
Sample 1

With the new interpreter, some on our testing PDF files are rendered as white rectangles when a gradient is used. We got correct rendering with 9.55.0.

Here are 3 (almost identical) samples. Samples 1 and 2 give colored rectangles with 9.55 but white rectangles with 9.56. Sample 3 gives the correct rendering with both 9.55 and 9.56.

We also get an error when we use -dNEWPDF=false, with the 3 samples:
**** Error reading a content stream. The page may be incomplete.
Output may be incorrect.
**** Error: File did not complete the page properly and may be damaged.
Output may be incorrect.

Thank you!
Comment 1 Guillaume Ayoub 2022-04-15 13:43:43 UTC
Created attachment 22410 [details]
Sample 2
Comment 2 Guillaume Ayoub 2022-04-15 13:44:01 UTC
Created attachment 22411 [details]
Sample 3
Comment 3 Guillaume Ayoub 2022-04-15 13:45:11 UTC
We have the problem converting the PDF into a PNG file, using:
gs -q -dNOPAUSE -dSAFER -dBATCH -sDEVICE=png16m -sOutputFile=gradient1.png gradient1.pdf
Comment 4 Ken Sharp 2022-05-19 16:02:36 UTC
Two of the files use an 'unusual' and rather over complicated definition of a gradient and also use unusual bounds for the parameteric variable; instead of ranging from 0 to N they range from -M to +N.

We were checking the wrong values for the Bounds of the sub functions, causing an error, which is fixed here:

bb53c6400abf474feb50125a4e438338fc6ba000

Note that sample 3 does not contain a gradient at all, which is why it is unaffected.

Thanks for the report.
Comment 5 Guillaume Ayoub 2022-05-19 16:14:28 UTC
(In reply to Ken Sharp from comment #4)
> Two of the files use an 'unusual' and rather over complicated definition of
> a gradient and also use unusual bounds for the parameteric variable; instead
> of ranging from 0 to N they range from -M to +N.
> 
> We were checking the wrong values for the Bounds of the sub functions,
> causing an error, which is fixed here:
> 
> bb53c6400abf474feb50125a4e438338fc6ba000
> 
> Note that sample 3 does not contain a gradient at all, which is why it is
> unaffected.
> 
> Thanks for the report.

Thanks a lot for the fix.

Sorry about the unnecessarily complicated gradients: these files are the results of unit tests trying crazy corner cases of CSS gradients…