| Summary: | Wavy lines disappear after re-distilling. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Alex Cherepanov <alex> |
| Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | michael.vrhel |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Customer: | Word Size: | --- | |
| Attachments: | Sample PDF file | ||
|
Description
Alex Cherepanov
2008-12-19 12:22:48 UTC
Created attachment 4664 [details]
Sample PDF file
For me the HEAD revision of GS is unable to correctly render the 'missing' portions of the job. Simply executing gswin32 results in those portions being rendered black. I also tried tiffsep in order to see each plate, and each plate is rendered incorrectly by comparison with Acrobat. I'm unsure where the problem truly lies, the job is fairly complex, including forms patterns and shading dictionaries, and the entire page is in a transparency group, so it may be a transparency problem. Michael, could you try this on the latest code in your branch please, and see if it renders correctly there ? From the PDF output it appears that some pattern colour spaces are being rendered as 0 0 0 RGB which is pretty clearly incorrect and (taking transparency into account) may be the whole of the problem. These are Shading patterns in the original PDF file, and these shading dictionaries *are* defined in the pdfwrite otuput, but they are never used, and no pattern spaces are defined for them. I have a sneaky suspicion that the same is happening when rendering, and its probably related to transparency. This being the case, fixing the rendering might well make the pdfwrite output correct as well. Retested with HEAD revision, and this file now works correctly for me. I believe that this has been fixed somewhere in the extensive work done by Michael on transparency. |