Fix so that we handle the \B command properly when we have transparency. The stroke should be drawn in a knock-out fashion rather than blended with the fill. This was achieved by adding in the push of a knockout transparency group for the stroke operation. The opacity for that group had to be 1 rather than what ever the current graphic state was (otherwise you end up with the opacity applied twice). That change revealed an issue in the clist when a transparency group is pushed where the opacity for the pdf14 clist device was being altered without having the information passed into the clist. Fixing that required a few changes to make sure that the blend parameter changes for the transparency group end up written in the same bands as the group push rather than all bands like the normal blend parameter change compositor action does. A few changes were needed in the clist compositor writing code to make sure that this special blend parameter change did not push a new cropping item on the cropping stack. This commit results in a lot of progressions. However, the cluster push revealed a couple files fts_06_0608.pdf.pdf.ppmraw for example, which may have an issue. These are being checked and if found to be an issue a new bug report will be filed.

git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@11914 a1074d23-0009-0410-80fe-cf8c14f379e6

1 files changed, 2 insertions, 0 deletions

diff --git a/gs/base/gstrans.h b/gs/base/gstrans.h
index 7f6380569..204261a83 100644
--- a/gs/base/gstrans.h
+++ b/gs/base/gstrans.h
@@ -114,6 +114,8 @@ struct gs_pdf14trans_params_s {
     gs_transparency_color_t group_color;
     int64_t icc_hash;
     cmm_profile_t *iccprofile;               /* The profile  */
+    bool crop_blend_params;  /* This is used when the blend params are updated
+                                during a transparency group push */
 
 };