The attached PDF files have a transparency layer on page 1. In trans.pdf GS8.53 display it as a black rectangle and in transBMP.pdf GS8.53 doesn’t show the layer. Steps to reproduce: 1. Load trans.pdf into GS8.53 and notice the black rectangle on page 1. Open the same PDF in Adobe Acrobat Reader and this shows as a transparency. 2. Load transBMP.pdf and the page 1 image does not have the circle transparency. Open the same PDF in Adobe and notice the transparency on page 1. This PDF 1.5, I’m using GS8.53 and winXP.
Created attachment 2106 [details] tran.pdf
Created attachment 2107 [details] tranBMP.pdf
I've double checked, and this bug still occurs with head (7749) as of 02/28/07.
Displaying with Ghostscript using -dNOTRANSPARENCY shows a solid cyan rectangle for trans.pdf, so we are probably doing the transparency in the wrong colorspace.
I was able to reproduce the bug as reported with tramBMP.pdf. I will use this file to research the issue. For tran.pdf the following error occurs: **** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. **** Warning: stream Length incorrect. **** Warning: stream Length incorrect. **** Warning: stream Length incorrect. **** This file had errors that were repaired or ignored. **** The file was produced by: **** >>>> Corel PDF Engine Version 3.0.0.576 <<<< **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. Error: /invalidrestore in --restore-- Operand stack: --nostringval-- Info --nostringval-- --nostringval-- --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1797 1 3 %oparray_pop 1796 1 3 %oparray_pop 1792 1 3 %oparray_pop --nostringval-- --nostringval-- 1738 3 4 %oparray_pop --nostringval-- 1722 3 4 %oparray_pop --nostringval-- --nostringval-- 1738 4 4 %oparray_pop --nostringval-- 1722 4 4 %oparray_pop --nostringval-- Dictionary stack: --dict:1083/1123(ro)(G)-- --dict:2/20(G)-- --dict:74/200(L)-- --dict:74/200(L)-- Current allocation mode is local Last OS error: 2 GPL Ghostscript SVN PRE-RELEASE 8.56: Unrecoverable error, exit code 1
OK... Even though Ghostscript bonks on tran.pdf, it does actually output an image that represents the problem as described.
I have looked at this bug report and actually implemented a fix that did produce the correct results for tranBMP.pdf. However, after moving on to look at tran.pdf I discovered that the fundamental problem is the same and therefore, I believe, that any valid fix should fix both cases. What I see as the fundamental problem is that we don't handle SoftMasks that are in what I would call a "standalone graphics state", which both of these jobs contain. Such SoftMasks should have their life-cycle managed along with the graphics state. This handling should deal with both gsave/grestores as well as a SoftMask changing from non-Null SoftMask to a SoftMask of "/None". As this work is largely in the pdf interpreter I'm reassiging this bug report to Alex. The problem I encountered with tranBMP.pdf turned out to be an ASCII download line ending issue. The file itself is OK. PDF should be archived to prevent these types of problems.
*** Bug 689309 has been marked as a duplicate of this bug. ***
Adding customer #1110 and bumping priority to match the duplicate bug #689309. Please see bug #689309 for more information and example files.
Created attachment 3187 [details] trani.pdf - corrected version of tran.pdf
Still occurs with r8748. Assigning to Michael for further investigation. Might this be related to not blending in the blend space?
This situation is urgent for this customer (1110) and should be a high priority for investigation. The customer added (via email to support): I've had a chance to look at the circumstances of this Blending problem, and have noticed something very definite about the cause: the drop shadow in the test file i sent (i believe it's "trani.pdf" in your attachment list) is created using an image, and that image is used as a Soft Mask in a "multiply" Blend Mode for a rectangle fill. The boundaries of the fill are larger than the Image used for the Soft Mask, and the unwanted dark bands are always in that part of the fill NOT covered by the soft mask. Does that make this issue any easier to fix? This is getting VERY annoying for our customers since it's VERY easy to create these things in InDesign.
Partial analysis using -dPDFSTEP and -dNOTRANSPARENCY (to determine where various parts are painted). 1. The "orange" circle is painted with the sequence: ----------------------------------------------------------------------------- /GS7 gs %Resolving: [10 0] 0.0 0.6 0.8 0.0 k 153.892303 210.683105 m 179.3069 210.683105 199.917099 190.072906 199.917099 164.6586 c 199.917099 139.244 179.3069 118.633904 153.892303 118.633904 c 128.478 118.633904 107.867897 139.244 107.867897 164.6586 c 107.867897 190.072906 128.478 210.683105 153.892303 210.683105 c f* ----------------------------------------------------------------------------- This is then "overlaid" with a Cyan rectangle (that appears solid black when rendered with transparency) by the sequence: ------------------------------------------------------------------------------ /GS11 gs %Resolving: [12 0] %Resolving: [15 0] %Resolving: [16 0] << /Resources << /ProcSet [ /PDF /ImageC ] /ExtGState << /GS10 17 0 R >> >> /Matrix [ 1.0 0.0 0.0 1.0 0.0 0.0 ] /Group << /S /Transparency /CS /DeviceRGB /Type /Group >> /FormType 1 /Subtype /Form /Length 1376 /BBox [ 69.1104 89.0274 196.688 239.482 ] /Type /XObject >> stream %FilePosition: 8690 endobj 1.0 0.0 0.0 0.0 k 69.1104 232.215 m 154.161606 232.215 l 154.161606 89.0274 l 69.1104 89.0274 l h f* ------------------------------------------------------------------------------ GS11 (object 12 0) has SMask 15 0 which is defined as: <</S /Luminosity /G 16 0 R /Type /Mask >> and object 16 0 is: << /Resources <</ProcSet [ /PDF /ImageC ] /ExtGState <</GS10 17 0 R >> >> /Matrix [ 1.0 0.0 0.0 1.0 0.0 0.0 ] /Group << /S /Transparency /CS /DeviceRGB /Type /Group >> /FormType 1 /Subtype /Form /Length 1376 /BBox [ 69.1104 89.0274 196.688 239.482 ] /Type /XObject >>stream 1.00000 0.00000 0.00000 1.00000 69.1104 89.0274 cm /GS10 gs q 0.0000 0.0000 127.5772 150.4551 re W* n 62.20232 -0.84072 2.05646 152.15158 31.6593 -0.4280 cm 0.00 0.00 0.00 0.00 k 0.1000 0.0000 -0.6417 1.0000 re f 0.00 0.00 0.00 1.00 k 0.9000 0.0000 0.6417 1.0000 re f BI /H 1 /W 256 /CS /CMYK /BPC 8 /F [] ID --------- DATA DELETED ----------------------- EI Q 0.0000 0.0000 127.5772 150.4551 re n endstream endobj The ID/EI sequence above (H=1, W=256) defines the "fountain fill" image that is intended to create the gradient effect. This is probably a case where the CMYK image is not being properly handled as a "SMask". Probably this is explained in Sect 7.4.2 of the PDF Reference Manual, but not properly handled in the code where it recommends that the luminosity derived from CMYK is defined. Note that the 'transfer function' is also mentioned which we may be missing, or we may be confused since the transparency group is RGB, but the image in the SMask is CMYK. I'll work with Michael to help dig into this, but I wanted to capture what I had seen so far.
BTW, the hex dump of the fountain fill (ID) data is: 00002320: 20 5B 5D 0A 49 44 20 00 00 00 00 00 00 00 00 00 | [].ID .........| 00002330: 00 00 02 00 00 00 02 00 00 00 05 00 00 00 05 00 |................| 00002340: 00 00 05 00 00 00 07 00 00 00 07 00 00 00 0A 00 |................| 00002350: 00 00 0A 00 00 00 0A 00 00 00 0C 00 00 00 0C 00 |................| 00002360: 00 00 0C 00 00 00 0F 00 00 00 0F 00 00 00 11 00 |................| 00002370: 00 00 11 00 00 00 11 00 00 00 14 00 00 00 14 00 |................| 00002380: 00 00 16 00 00 00 16 00 00 00 16 00 00 00 19 00 |................| 00002390: 00 00 19 00 00 00 1C 00 00 00 1C 00 00 00 1C 00 |................| 000023A0: 00 00 1E 00 00 00 1E 00 00 00 21 00 00 00 21 00 |..........!...!.| 000023B0: 00 00 21 00 00 00 23 00 00 00 23 00 00 00 26 00 |..!...#...#...&.| 000023C0: 00 00 26 00 00 00 26 00 00 00 28 00 00 00 28 00 |..&...&...(...(.| 000023D0: 00 00 28 00 00 00 2B 00 00 00 2B 00 00 00 2D 00 |..(...+...+...-.| 000023E0: 00 00 2D 00 00 00 2D 00 00 00 30 00 00 00 30 00 |..-...-...0...0.| 000023F0: 00 00 33 00 00 00 33 00 00 00 33 00 00 00 35 00 |..3...3...3...5.| 00002400: 00 00 35 00 00 00 38 00 00 00 38 00 00 00 38 00 |..5...8...8...8.| 00002410: 00 00 3A 00 00 00 3A 00 00 00 3D 00 00 00 3D 00 |..:...:...=...=.| 00002420: 00 00 3D 00 00 00 3F 00 00 00 3F 00 00 00 3F 00 |..=...?...?...?.| 00002430: 00 00 42 00 00 00 42 00 00 00 44 00 00 00 44 00 |..B...B...D...D.| 00002440: 00 00 44 00 00 00 47 00 00 00 47 00 00 00 49 00 |..D...G...G...I.| 00002450: 00 00 49 00 00 00 49 00 00 00 4C 00 00 00 4C 00 |..I...I...L...L.| 00002460: 00 00 4F 00 00 00 4F 00 00 00 4F 00 00 00 51 00 |..O...O...O...Q.| 00002470: 00 00 51 00 00 00 54 00 00 00 54 00 00 00 54 00 |..Q...T...T...T.| 00002480: 00 00 56 00 00 00 56 00 00 00 59 00 00 00 59 00 |..V...V...Y...Y.| 00002490: 00 00 59 00 00 00 5B 00 00 00 5B 00 00 00 5B 00 |..Y...[...[...[.| 000024A0: 00 00 5E 00 00 00 5E 00 00 00 60 00 00 00 60 00 |..^...^...`...`.| 000024B0: 00 00 60 00 00 00 63 00 00 00 63 00 00 00 66 00 |..`...c...c...f.| 000024C0: 00 00 66 00 00 00 66 00 00 00 68 00 00 00 68 00 |..f...f...h...h.| 000024D0: 00 00 6B 00 00 00 6B 00 00 00 6B 00 00 00 6D 00 |..k...k...k...m.| 000024E0: 00 00 6D 00 00 00 70 00 00 00 70 00 00 00 70 00 |..m...p...p...p.| 000024F0: 00 00 72 00 00 00 72 00 00 00 72 00 00 00 75 00 |..r...r...r...u.| 00002500: 00 00 75 00 00 00 77 00 00 00 77 00 00 00 77 00 |..u...w...w...w.| 00002510: 00 00 7A 00 00 00 7A 00 00 00 7C 00 00 00 7C 00 |..z...z...|...|.| 00002520: 00 00 7C 00 00 00 7F 00 00 00 7F 00 00 00 82 00 |..|...⌂...⌂.....| 00002530: 00 00 82 00 00 00 82 00 00 00 84 00 00 00 84 00 |................| 00002540: 00 00 87 00 00 00 87 00 00 00 87 00 00 00 89 00 |................| 00002550: 00 00 89 00 00 00 8C 00 00 00 8C 00 00 00 8C 00 |................| 00002560: 00 00 8E 00 00 00 8E 00 00 00 8E 00 00 00 91 00 |................| 00002570: 00 00 91 00 00 00 93 00 00 00 93 00 00 00 93 00 |................| 00002580: 00 00 96 00 00 00 96 00 00 00 99 00 00 00 99 00 |................| 00002590: 00 00 99 00 00 00 9B 00 00 00 9B 00 00 00 9E 00 |................| 000025A0: 00 00 9E 00 00 00 9E 00 00 00 A0 00 00 00 A0 00 |................| 000025B0: 00 00 A3 00 00 00 A3 00 00 00 A3 00 00 00 A5 00 |................| 000025C0: 00 00 A5 00 00 00 A5 00 00 00 A8 00 00 00 A8 00 |................| 000025D0: 00 00 AA 00 00 00 AA 00 00 00 AA 00 00 00 AD 00 |................| 000025E0: 00 00 AD 00 00 00 AF 00 00 00 AF 00 00 00 AF 00 |................| 000025F0: 00 00 B2 00 00 00 B2 00 00 00 B5 00 00 00 B5 00 |................| 00002600: 00 00 B5 00 00 00 B7 00 00 00 B7 00 00 00 BA 00 |................| 00002610: 00 00 BA 00 00 00 BA 00 00 00 BC 00 00 00 BC 00 |................| 00002620: 00 00 BF 00 00 00 BF 00 00 00 BF 00 00 00 C1 00 |................| 00002630: 00 00 C1 00 00 00 C1 00 00 00 C4 00 00 00 C4 00 |................| 00002640: 00 00 C6 00 00 00 C6 00 00 00 C6 00 00 00 C9 00 |................| 00002650: 00 00 C9 00 00 00 CC 00 00 00 CC 00 00 00 CC 00 |................| 00002660: 00 00 CE 00 00 00 CE 00 00 00 D1 00 00 00 D1 00 |................| 00002670: 00 00 D1 00 00 00 D3 00 00 00 D3 00 00 00 D6 00 |................| 00002680: 00 00 D6 00 00 00 D6 00 00 00 D8 00 00 00 D8 00 |................| 00002690: 00 00 D8 00 00 00 DB 00 00 00 DB 00 00 00 DD 00 |................| 000026A0: 00 00 DD 00 00 00 DD 00 00 00 E0 00 00 00 E0 00 |................| 000026B0: 00 00 E2 00 00 00 E2 00 00 00 E2 00 00 00 E5 00 |................| 000026C0: 00 00 E5 00 00 00 E8 00 00 00 E8 00 00 00 E8 00 |................| 000026D0: 00 00 EA 00 00 00 EA 00 00 00 ED 00 00 00 ED 00 |................| 000026E0: 00 00 ED 00 00 00 EF 00 00 00 EF 00 00 00 F2 00 |................| 000026F0: 00 00 F2 00 00 00 F2 00 00 00 F4 00 00 00 F4 00 |................| 00002700: 00 00 F4 00 00 00 F7 00 00 00 F7 00 00 00 F9 00 |................| 00002710: 00 00 F9 00 00 00 F9 00 00 00 FC 00 00 00 FC 00 |................| 00002720: 00 00 FF 00 00 00 FF 0A 45 49 0A 51 0A 30 2E 30 |........EI.Q.0.0| Thus the data is entirely in the 'K' channel.
The gradient CMYK image with all the data in K is getting mapped to RGB (at least if the output device is RGB) and not to a luminous type value. If the output device is CMYK the image remains in CMYK and is not remapped. I don't see anywhere that it is getting converted to a luminous value like it should as Ray mentioned. Also, I don't see anywhere that GS knows to treat this image data as a soft mask.
Created attachment 4164 [details] trani2.pdf This file uses the same CMYK source image as the other file as a soft mask. This file works however. It ends up converting CMYK to RGB. It looks like with this file we create the transparency mask for the image which is composited with the cyan square using just one of the RGB channels from the mask. I don't see this happening in the original file though. Need to dig a bit further to understand the difference between these two as I think this is the key.
I think the problem is that our implementation of SMask does not allow for painting individual objects with an SMask. The SMask in question is being ignored (it is stored in ctx->maskbuf, but it is never used in subsequent pop_transparency_group operations). The other problem seems to be that the "f*' fill of the rectangular area is actually being filled with black (color=0x0000000000000000) instead of Cyan. I modified the coordinates of the rectangular fill and verified that this changed the coordinated of the -Zv output for the pdf14_mark_fill_rectangle. I suspect that (1) we aren't properly compositing objects when a SMask has been set -- we collect the SMask, but then ignore it. This may have been missed since mostly the PDF transparency spec. discusses transparency groups, but from section 7.5.3 under "Mask Shape and Opacity" it suggests to me that "objects", not just transparency groups can have an SMask applied: "Note: The current soft mask in the graphics state is intended to be used to clip only a single object at a time (either an elementary object or a transparency group). If a soft mask is applied when painting two or more overlapping objects, the effect of the mask multiplies with itself in the area of overlap (except in a knockout group), producing a result shape or opacity that is probably not what is intended. To apply a soft mask to multiple objects, it is usually best to define the objects as a transparency group (see Specifying SECTION 7.5 Transparency in PDF) and apply the mask to the group as a whole." A quick, but not exactly conforming approach, _might_ be to push a transparency group when an ExtGState is invoked, just prior to pushing the transparency mask, then pop it when the ExtGState changes. The reason this is not conforming is that it won't produce the "probably unintended" effect described in the PDF Reference Manual. I will attempt editing a version of this PDF to introduce a transparecny group to encompass the area where GS7 (with the SMask) is effective (up to the GS12). Note that there is a ".begintransparencymaskgroup" (ztrans.c::zbegintransparencymaskgroup) but this doesn't impose any 'group', and there is no corresponding 'pop' (since a transparency group isn't pushed) so the SMask compositing never happens. ---------- I don't yet have any insight into the second problem, where the Cyan color is lost (or replaced with Black).
Created attachment 4171 [details] compare.png Customer is suspicious that the issues we are seeing with 688601 are not related to their original bug posted as 689309. Attached is a screen shot of their original file rendered with AR and the current head version. This does appear to be a case of the soft mask getting ignored like we are seeing in trani2.pdf. The original clipping issue the customer observed in earlier releases no longer appears to occur.
Created attachment 4173 [details] GS_with_patch_vs_AR_7.png The problem with the Cyan color being Black is actually in the PDF interpreter. The 'setfillstate' proc has the correct FillColor and FillColorSpace values of DeviceCMYK [ 1 0 0 0 ] color (Cyan), but then the it executes 'setfillblend' which executes fills the SMask which changes these values. The same thing happens with the StrokeColor. I modified lib/pdf_ops.ps to save these values on the stack (as a quick and dirty patch) and this attachment is now the results from Ghostscript. The minor color differences are _probably_ because the CRD I am using is not the same as Adobe (note, I _did_ use the USWebCoatedSWOP as the DefaultCMYK ColorSpace). I will consult with Michael to decide how to handle this properly (we will probably need to involve Alex as well).
Created attachment 4175 [details] 688601.patch This patch fixes the customer's original problem with the "gray" text being black as well as the Cyan Rectangle in the trani.pdf becoming Black. This does _not_ fix the problem in the simple test case (trani.pdf) where the SMask in the ExtGState is solid (SMask ignored) so the (Cyan) rectangle is still solid.
Our standard regression testing shows no differences but ps2pdf script generates 2 incorrect PDF files with the patch. This happens with SoftMaskGroup.pdf and Bug689369.pdf
Assigning this to Alex to follow up -- it seems we are getting close, but the pdfwrite problem is a concern.
BTW, the missing SMask issue has been opened as a new bug 689931. As far as we know this is not a customer bug. I've created a modified test file to show differences between Adobe and Ghostscript better.
Created attachment 4180 [details] patch - compatible with pdfwrite Restore current color and color space after rendering soft mask. Earlier code restored the color space only and implicitly set default color - black. Change the comments to reflect the changes made by rev. 6079.
While the patch of attachment 4180 [details] (comment #24) works OK with the 'transillus.pdf' (attachment 3100 [details] of bug 689309) of the customer's original bug report, it does _NOT_ give the correct color (Cyan) on trani.pdf (attachment 3187 [details], comment #10). Furthermore, it does not account for all of the other ExtGState and gstate parameters that might be modified by (possibly nested) SMask operations. I suggest that the patch of comment #20 is closer to what is actually needed, but with something to handle the smask ID so that it is comatible with pdfwrite.
Changing the bug assignment because the paroblem falls to kernel assumptions about data ownership and interchange between subsystems. It requires changes to several subsystems including the graphioc state, transparency stuff and pdfwrite. It definitely can't be resolved at the PDF interpreter level only.
IMHO, having a device (pdfwrite) store state information in the imager_state violates the design of the graphics library / device layer. Perhaps setting a unique ID from PostScript into the SoftMask dict could be used by the pdfwrite to detect the state change in the device so that the 'q ... Q' bracketing could be used around the SMask collection (begin_transparency_mask ... end_transparency_mask). In general, I am fairly certain that the graphics state changes of 'running' the SMask painting operations need to be isolated from the Content stream graphics state. Since this now impinges on pdfwrite, I'm adding Ken to the CC list.
I'm not sure that Igor should usurp ownership of this problem. Clearly it overlaps several areas -- pdfwrite (Ken's), PDF interp (Alex) and transparency (Michael). A collaborative effort between these three actually seems to be called for. Adding Alex to the cc list since he got dropped when Igor took ownership.
IMO the ownership needs a correction. Michael owns colors, so his module is gxblend.c . gdevp14.c and gstrans.c should be considered as a part of kernel due to complex interaction with clist.
This problem requires a design document detailing all the needed changes submitted to tech in advance of fixing the problem. Each member of the staff will ok the proposal before any changes.
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.
The way newer graphics libraries deal with this is to provide intermediate image buffers for storing smasks transparency groups and so on, similar to high level images. Interpreters can manipulate and cache these as appropriate, as well as setting them in the graphics state to affect current drawing. I'm not clear how easily we can do this, but it's clear that the ideal of a device chain ideal in Ghostscript is becoming increasingly strained. On IRC yesterday, Michael and I discussed adding begin/end softmask device methods, with gx_default_end_softmask closing the temporary memory device and storing the result in the graphics state. This would allow high level devices to collect (even vector) soft masks while automatically flattening them for other devices. I presume in this model the smask clipping of further drawing would be done by an interposed device just like with transparency groups.
Regarding comment #32 : 1. Any buffering to be applied after clist. 2. We already implement device methods for bebin/end soft mask. What we do not is a caching an already rasterized mask. BTW shadings demonstrate same problem. IMO you guys again look in a wrong ditrection. The key problem is to comply soft_mask_id storage with gsave/grestore. All other issues are minor. BTW I suspect that the patch 4715 can be brought to the life with a relatively small effort. Maybe I'm wrong, because I didn't study this part of gs/lib . I *guess* the patch 4715 implements the sequence : gsave .begintransparencymaskgroup exec_group .endtransparencymask grestore That's why it miss soft_mask_id from the graphic state. The right sequence it : .begintransparencymaskgroup gsave exec_group grestore .endtransparencymask Something like this may be done with qQ in gs/lib as well.
fix priority and customer field.
IMO the best way to fix this and other similar issues in HEAD is to change ownership of the modules gstrans.c and gdevp14.c to me. I believe that the ownership of the was choosen from scratch, and the current owner would be happy to get rid of them. These modules are not related to colors. Alternatively give them to Alex because me and he collaborate with no problem.
reassigned at color meeting.
Comment on attachment 4180 [details] patch - compatible with pdfwrite This patch doesn't work with the file attached to bug 689931. Please see that bug for an improved patch.
This renders properly with the soft mask branch.
This renders correctly with the soft mask branch.