Mental, what are your thoughts on this approach?
On Wed, Aug 09, 2006 at 09:44:37PM +0200, Ulf Erikson wrote:
Bryce Harrington wrote:
On Wed, Aug 09, 2006 at 03:45:04PM +0200, Ulf Erikson wrote:
I would like to improve the pdf exporter by handle clippaths
Should it be possible to continue using a "print" extension or do I need to start use an "output" extension for this? I understand that an output extension is handed the full document tree at once. A print extension on the other hand is given a single path at a time together with the needed style, transformation matrix, bounding box, and so on. But I don't see if and how a print extension can get information about the needed clipping path.
Sounds like you probably want to switch to using an "output" extension.
Well.. I guess that way I would have all information at hand, but it also looks more complicated to even get started. If it is not needed I prefer to stay with a print extension
Maybe I was hoping there would be a magic sp_get_current_clippath() function of some kind. I keep finding new functions that manage to dig out the information I am looking for. But there is no chance on this one? ;-)
If there is no information about the clippath available for print extensions would it be okay to add this (by changing the interface)? Is it then better with a new set_clippath method or an extra clippath parameter for the fill and stroke methods?
Maybe... I don't really follow what you mean; can you describe it a bit more?
I'll try..
I think a reference to the clippath to be used on a path is held in clip_ref of SPItem. The fill() and stroke() functions of a print extension are called from sp_shape_print() in sp-shape.cpp. This is an excerpt of the current code:
if (style->fill.type != SP_PAINT_TYPE_NONE) { NRBPath bp; bp.path = SP_CURVE_BPATH(shape->curve); sp_print_fill (ctx, &bp, i2d, style, &pbox, &dbox, &bbox); }
Adding the clippath as a parameter to fill() seems like a minor change (maybe like this?)
if (style->fill.type != SP_PAINT_TYPE_NONE) { NRBPath bp; bp.path = SP_CURVE_BPATH(shape->curve); SPClipPath *cp = item->clip_ref->getObject(); sp_print_fill (ctx, &bp, i2d, style, &pbox, &dbox, &bbox, cp); }
This would be easy enough and straight forward, but.. I guess you can use a clippath on a group of paths and that would lead to quite some duplicate definitions of the same clip path. It might thus be better to have a function pair like: sp_print_set_clippath( item->clip_ref->getObject() ); and sp_print_release_clippath(); in a way similar to the bind/release pair for transformations. I'm still not sure where those two would have to be added though..
The next idea is new and not thought through.. maybe the clippath push and pop could even be added to the current bind/release functions?
Offhand, I'd say go ahead and try it. We usually encourage people to "patch first, discuss later" since it's usually easier to decide if something is the right way, after there is some tangible code to try out.
Okay, but I am still interested in hearing more ideas and suggestions. When/if I have something to show you will find it in the patch tracker.
Ulf