summaryrefslogtreecommitdiff
path: root/source/tools/mudraw.c
diff options
context:
space:
mode:
authorRobin Watts <robin.watts@artifex.com>2017-09-08 12:39:43 +0100
committerRobin Watts <robin.watts@artifex.com>2017-10-24 15:16:36 +0100
commitfbdd9c7c1bda2081e49b82a3a0d9ca5cf7abe492 (patch)
treea40e3b52e1eb62397bfa5404433cb63a531f965b /source/tools/mudraw.c
parent313c72b9b3f3c888a51c9eb02187228b9e2aad11 (diff)
downloadmupdf-fbdd9c7c1bda2081e49b82a3a0d9ca5cf7abe492.tar.xz
Fix "CompatibleOverprint" blend mode.
This is a wierd one. After much panicing about this, it seems that all that is required to get the correct result is to ensure that the groups used by MuPDF to wrap graphical objects displayed in non-Normal blend modes is a non-isolated (non-knockout) one. The PDF spec is written assuming that blending happens at object plotting time. MuPDF does not work in this way. We only support normal blend mode plotting. To achieve non-normal blend modes, we therefore wrap each object in a group. The object is plotted 'normally', and then the end of the group causes the blend to be applied as required. Our plotters *do* know about overprinting, hence only the required components are changed. By using a non-isolated group, the background is copied in, and overprint correctly chooses not to alter the appropriate components. This means that when blending back, the background components match the source components for overprinted components. Thus (to put it in terms used in the PDF spec) cb = cs for all overprinted components. Hence if we use B(cb,cs) = cs (i.e. normal blend mode), we get what is required by CompatibleOverprint mode. Thus plotting into our group 'Normally, with overprint', and then blending back with the specified blend mode, appears to give exactly what we need.
Diffstat (limited to 'source/tools/mudraw.c')
0 files changed, 0 insertions, 0 deletions