MenTaLguY wrote:
Hmm, I don't know. I think the printing API needs to expose clippaths somehow anyway, so we may as well augment that rather than moving everything over to the "output" API. (At some point we'll also need to consider whether we can merge the two APIs, though...)
I think that the output extension is actually the "correct" one to use. They are the ones shown in the SaveAs dialog. The ps, pdf and some more exporters have two extensions; one output extension that includes a full copy of sp_print_document_to_file() only to be able to chose another printer context than the default postscript printer; and one print extension that actually writes the file.
How about building an output extension that implements the print extension interface? Other extensions could then inherit this funtionality and let you write an output extension by using the simpler print extension interface.
Now, this would probably be simpler to do if there was an SPShape::print() instead of the sp_shape_print().. and the same for all other SPItem items
Since clippaths accumulate (via intersection) from parent to child, so it probably is something we should make part of the state that is push/popped.
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. 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()).