On Thu, 2006-08-10 at 16:46 +0200, Ulf Erikson wrote:
Isn't the print extension mainly for printing to postscript? If both postscript and pdf are able to intersect clip paths there wouldn't be a need to keep that in the state. It would be enough to tell when to push/pop a clip path.
Well, the way that it works in Postscript level <= 2 is that the clipping path is simply part of the gstate. There's a 'clip' operator (and an 'eoclip' variant for the even-odd fill rule) which computes the intersection of the current path and the current clipping path and makes that the new clipping path. If you want to save and restore the clipping path, that has to happen as part of saving and restoring the gstate as a whole.
Postscript Level 3 does introduce 'clipsave' and 'cliprestore' operators, but for our purposes I think it might actually be preferable to stick with saving and restoring via the gstate, since we're doing it anyway.
What do you think of adding such a push/pop pair for the clip path in sp_item_invoke_print()? (since the clip path is already handled in sp_item_invoke_show()).
That seems reasonable.
-mental