[gs-bugs] [Bug 688601] PDF v1.5 file we don't display correctly using GS 8.53

Fri Jul 4 17:00:04 PDT 2008

http://bugs.ghostscript.com/show_bug.cgi?id=688601

------- Additional Comments From leonardo at artifex.com  2008-07-04 17:00 -------
Well here is "documentation" upon Henry's request.

For a proper handling of transparency the PDF interprteter needs to maintain a 
transparency stack. Due to a poor basic desing in the past, the stack is a 
property of a device. Currently we have got 2 devices, which maintain the 
stack - pdf14 and pdfwrite. Raster devices install the pdf14 device when a 
tarnsparency occurs. pdfwrite installs pdf14 if it needs to comvert 
transparency into a bitmap, otherwise it maintains the transparency stack 
internally, and this implementation is almost dummy. Other devices (such as 
pclwrite) convert transparency into billions of rectangles.

This architecture doesn't allow to factor out the transparency processing from 
specific output formats, especially from high level formats. For example, when 
we'll start an implementation of xpswrite, we'll need to maintain the 
transparency stack inside xpswrite, and a sharing of code from pdfwrite is 
almost impossible due to PDF-specific data structures.

In the past there were several attempts to associate a transparency stack with 
imager state. Rather we still keep roudiments of those attempts in the 
codebase, all them had failed. The reason is that we have no single imager 
state, but a stack of them, plus "isolated" chains of imager states, which may 
be set with setgstate.

So now I can coresee 3 possible ways to fix this bug. 

1. The simplest way is to move soft_mask_id from the imager state to 
gx_device_pdf. Doing this step we will go away from the "right" architecture. 
This way is a pretty small change, but it makes the general architectural 
problem become deeper.

2. Associate a transparency layer with an imager state. It means that we'll 
execute gsave when starting each transparency group, and grestore when 
finishing it (Ray's Qq fall here). This is more or less straightforward, but 
it is not compatible with setgstate. A possible resolution is to restrict 
setgstate with special constraints, which don't allow to jump to another 
branch of the transparency tree. Nevertheless this way requires very deep 
changes to the transparency engine. 

3. Make an interpreter instance structure be accessible through the device 
interface, and associate the transparency stack with it. It means that all 
interpreters must be derived from a single base class. It will allow us to 
maintain global resources for all interpreters in the multilanguage build 
(such as font cache or halftone cache), but of cause this change is more big 
because it affects all interpreters. Not sure what will happen here with 
Display Postscript.

Besides that, there exist another architectural problem, which is not visible 
right now, but it will be visible (1) when choosing the way 2, and (2) when 
pdfwrite meets a transparent object, which can't be written into the output as 
a high level object. The problem is that currently the color converter is a 
property of a device. Now a single pdf14 device serves conversions for any 
blending space, and changes its output color format dynamically when entering 
a transparency group. This behavior immediately attached to the clist logic, 
so it can't change easy. Since pdf14 device is a kind of singleton, gstate-
setgstate can't properly work with it. This problem also will be visible when 
implementing multiple instances of color converter.

One more problem is caching transparency masks. If 2 gs commands refer to same 
ExtGState object, which includes an SMask, the soft mask group is interpreted 
2 times. More commands more interpretations. This is a great leak of the 
performanse, which can't be fixed neither within the curent architecture, nor 
within the way 1 or 2.

At last there exist one more problem, which was never mentioned before now. 
The problem is an overprint in a transparency group. I'm not sure what happens 
now because we still haven't recieved such documents from customers. 
Nevertheless it is allowed by the PDF spec. I guess such construction in the 
best case will be converted into billions of rectangles, and in the worst 
csase will cause a crash, becausde nobody took care about superposing 
compositors. Nobody even thought that they are possible and how they should 
interact with the clist writer. Likely only way to resolve it is to emulate 
overprint with transparency.

So here we will be triggered by one main disagreement between me and Henry : 
are we a bug driven company, or not ? This bug drives us to the way 1. Will 
see.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.