Comment 26 for bug 168627

JiHO:
> With vectors it is not as easy: how to determine what is outside of
> the document? You could remove all objects which don't have any node
> in the document, or remove all those which bounding boxes do not
> intersect with the document.

I was thinking about the latter. I'm not a programmer so I don't know if my solution would work ;) The point is to avoid objects outside of the page limits *without* altering any object that is part of the artwork. In my opinion this should be done the following way: the export routine checks if there is anything on the page area. In theory, we know the area (width, length) and coordinates (x,y) of the page and the objects. Would a routine that checks if any object is inside page's area be too hard to code?

I think we agree on this as a hypothetical solution.

Then, with good reason, you mention how objects bounding boxes would be measured. There are many cases:
* Paths, shapes and 3d cubes: these may have strokes that go outside of the path, so the visual bounding box should be used.
* LPEs: basically they're paths. Use visual bbox.
* Groups: treat them the same as any other object. If there are objects inside and outside of the page, always leave the whole group intact. In other words: don't ungoup, delete offlimits objects, regroup. Is not needed. If the user has grouped some objects it's because there was a conscious decision made. The software has to respect that.
* Clipped and masked objects: currently, when you select a clipped/masked object, the selection is the bounding box of the clip path or mask. That's the visible part and what should be used. If there are groups inside of the clip/mask but not intersecting with the page, leave them (same treatment, as with groups).
* Clones and LPEs linked to paths: for the clones that are part of the artwork, use same method as for shapes and paths. If we want to play safe, clones which have a parent outside should have their parent kept --wherever it is. Paths linked to a LPE should be kept. However, for EPS/PDF this is not necessary as these two formats don't support clone hierarchy, nor LPE (correct me if I'm wrong).
* Filtered objects: These can sometimes go way beyond the geometric shape, so use visual bbox.

I don't see the need for a bool-op at all. That would degrade the objects and cause unpredictable behaviors under some circumstances. The routine described above would export everything that's part of the artwork without compromising the look of it. Also, even when exported to "lossy" formats such as PDF, there is still a chance of making small corrections to the objects over the page's border, whereas the bool-ops would cut parts of them.

> Finally, what's maybe more important is what I said above about the
> way PDF works. There are several boxes and the one corresponding to
> the page is the crop box. And for a PDF, crop is non destructive.
> So people might actually expect the behavior you want to suppress (i.e.
> retaining objects outside of the page).

I could argue that we are *people* too :P ;-)

> Every other software that I can think of works this way at least.

It seems that Enfocus PitStop (an Acrobat plug-in for checking and editing PDF) has a tool for doing that: deleting everything outside the crop box.

> Making it an option would conciliate those use cases
> but I this would just be a band aid fix on a more general problem
> (lack of support for these PDF boxes)... and a band aid that would
> require a lot of work!

Can't agree here. These are not excluding things. People who want this option is not because they can't "crop" their artwork (they can already move it to the page and export), it is because the resulting file will include objects and images that are not needed nor intended to be shared at all, thus bloating the filesize.

Regards.