Tweak mupdf clip path handling.

In the existing mupdf clip path code, it would be possible for us to
render incorrectly; consider the following fragment of a content
stream:

 0 0 100 100 re
 W
 50 50 100 100 re
 f

That should set the clip path to the (0, 0) -> (100, 100) rectangle,
and then attempt to fill both the (0,0) -> (100,100) rectangle and the
(50,50) -> (150,150) rectangle, resulting in just the (0,0) -> (100,100)
rectangle being filled.

In the existing mupdf code, it would actually fill both rectangles as
the path after the W operation (the addition of the second rectangle)
would also affect the stored clip path.

We solve this by doing the clip operation on the W operator, rather than
deferred to when the path is actually disposed of.

0 files changed, 0 insertions, 0 deletions