diff options
author | Robin Watts <robin.watts@artifex.com> | 2017-09-08 12:39:43 +0100 |
---|---|---|
committer | Robin Watts <robin.watts@artifex.com> | 2017-10-24 15:16:36 +0100 |
commit | fbdd9c7c1bda2081e49b82a3a0d9ca5cf7abe492 (patch) | |
tree | a40e3b52e1eb62397bfa5404433cb63a531f965b /source/tools/mudraw.c | |
parent | 313c72b9b3f3c888a51c9eb02187228b9e2aad11 (diff) | |
download | mupdf-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