RFE: 'export selection' to vector formats (PDF, eps,...)

Originator: NO

just delete the offending objects?

Originator: YES

> just delete the offending objects?

I am not talking about inconvenience of such functionality here. This is
the bug of pdf export in inkscape. If some objects are exported - they
should be visible on the page. If you can not see these objects in pdf
viewer then why are they included in the file?

Originator: NO

The behaviour you described here is the normal behaviour for the PDF and
EPS formats. The page is the bounding box, objects can be placed inside or
outside of it. Deleting the objects placed outside the bounding box (page)
is not the expected behaviour, as it is very actual in PDFs exported for
printing. In certain cases some specific marks (or comments) can be placed
outside of the bounding box (which is then the "clean" printed area) but
can be still used by the printer. A good example is the so called "slug"
area, placed outside the bounding box, and even outside the bleed area.

Another use of objects placed outside the page are keywords. Some
cataloging/indexing systems place tags into exported PDF files outside of
the bounding box so they are not visible to readers/viewers, but still can
be found/indexed by these systems thanks to these "invisible" portions of
texts/tags/keywords.

I'd say that it is not a bug, and should be transformed into a feature
request, something like a PDF export settings window where you can select
between export possibilities (see the screenshot of Corel's PDF export
setting window I attached to this post).

The only possibility to get rid of these objects placed outside of the
page is to delete these objects before export, or export only selected
objects. Corel Draw's default behaviour is to export PDFs including the
objects outside the page, but has also the possibility to export only
selected objects.

By the way, how did you manage to import a PDF generated by Inkscape
(Cairo 1.4.6) into Corel Draw? I have Corel 12 and it says that the PDF fle
is broken. When I open the PDF in Acrobat 5.0, it rebuilds it before
showing...

Looks like PDF produced by Cairo aren't very "kosher".
File Added: corel_pdf_export_settings.png

Originator: YES

> The behaviour you described here is the normal behaviour for the PDF and
EPS formats. The page is the bounding box, objects can be placed inside or
outside of it. Deleting the objects placed outside the bounding box (page)
is not the expected behaviour, as it is very actual in PDFs exported for
printing. In certain cases some specific marks (or comments) can be placed
outside of the bounding box (which is then the "clean" printed area) but
can be still used by the printer. A good example is the so called "slug"
area, placed outside the bounding box, and even outside the bleed area.

O. I agree here. Apparently, I misunderstood the inkscape inteface,
assuming that if regular PDF Viewer does not display the objects beyond the
page boundary, and inkscape does not ask anything before export, then the
only exported objects are within the page area.

> I'd say that it is not a bug, and should be transformed into a feature
request,

agree. Current behavior is dumb and User needs a choice. Same with .eps
files. Although, we have a choice when exporting to bitmaps.

> By the way, how did you manage to import a PDF generated by Inkscape
(Cairo 1.4.6) into Corel Draw? I have Corel 12 and it says that the PDF
file is broken.

same here.

> When I open the PDF in Acrobat 5.0, it rebuilds it before showing...

more than that... If you save that rebuilt file from Acrobat - it destroys
all the objects behind the page boundary. So apparently this is what I have
to do with my files in order to get rid of garbage.

Actually I cheated. I created a latex document using pdftex, with my image
(exported from inkscape) included.
The resulting document can be opened in corel draw and all the objects are
exposed, although you cant see them previewing the document in Acrobat.
However, there is also that Sumatra PDF viewer
(http://blog.kowalczyk.info/software/sumatrapdf/) which also shows the
extra objects because of the bag (or maybe feature in the software)

Originator: NO

Which version of Inkscape are you using? With a recent version:
- the crop box and the media box of the pdf seem to be the same: the page
border. hence I cannot see objects outside the page
- pdf exported by Inkscape with objects outside the page are included just
fine in latex documents with pdflatex and I don't see the objects outside
the page
It would be particularly helpfull to know which version of Cairo your PDF
exporter is using. Mine is 1.4.6.

Originator: YES

> Which version of Inkscape are you using?

0.45

> With a recent version:
> - the crop box and the media box of the pdf seem to be the same: the
page
border. hence I cannot see objects outside the page
> - pdf exported by Inkscape with objects outside the page are included
just
fine in latex documents with pdflatex and I don't see the objects outside
the page

I also used to think so, but the question is what tool are you using for
.pdf preview.

> It would be particularly helpfull to know which version of Cairo your
PDF
exporter is using. Mine is 1.4.6.

have no idea how to check this under windows (I'm working at windows box
right now).

This topic probably no longer makes a sense, because it appears to me that
this is not a bug but just the absence of the feature. However, to convince
you I'll spend some time.

I'm including couple attached files:

inkscape_bugreport.svg - original, simple inkscape svg file

inkscape_bugreport.svg.pdf - pdf file generated from svg file using
inkscape

inkscape_bugreport.svg.pdf.emf - .emf file generated by inkscape (I just
recently found out that this can be demonstrated on other formats)

inkscape.pdf .pdf fiel produced from .tex document with pdflatex

as you can see in .svg file, nesides the couple objects that fit on a
page, there is another rectangle outside the page are. Obviously, if you
generate pdf. or .emf, you are not supposed to see the last object, because
it is outside the bounding box. Indeed, you do not see it using the regular
methods.
However, if you include the inkscape_bugreport.svg.pdf file in latex
document with pdflatex and use Sumatra PDF Viewer to display the resulting
file (http://blog.kowalczyk.info/software/sumatrapdf/) you will be
surprised. So you may call it a bug in Sumatra (th only prd viewer whic I
found to be able to reveal hidden objects), but it just proves that the
object is included in the file, which is essential here.

Another method, using .emf file produced by inkscape. Insert this file in
MS Powerpoint slide. Initially you will not see the third object. But if
you ungroup the diagram, it will show up.

File Added: inkscape_bugreport.svg

Originator: YES

File Added: inkscape_bugreport.svg.pdf

Originator: YES

File Added: emf-test.svg.emf

Originator: YES

File Added: inkscape.pdf

Originator: NO

thank you for the example files, they will be useful in the future. I am
sorry but I cannot check with sumatra pdf (I am working on a mac) but
apparently latex treats the pdf file correctly because its position in the
resulting pdf does not seem to take in account the object outside the page,
only the page itself. displaying objects outside the bounding box is a
feature indeed, but should only be activated when the user asks for it
(such as selecting the display of the media box, bleed box or such). Are
there such options in sumatra PDF viewer?
As for the export in Inkscape, it would indeed be very nice to have as
much flexibility in vector export that in raster export (export only page,
only selection, etc. You could search for a RFE about this and add one if
necessary, that would be welcome). However, discarding some parts of a
vector drawing would probably have to be done by clipping/masking it and
this is also non desctructive (the clipped part are not displayed any more
but are still there). If one wants to actually suppress everything outside
an area, this has to be done via boolean operations and their results are
non trivial as soon as there are some complex, self intersecting paths that
would have to be cut by these operations. You can try them from Inkscape
currently and see how difficult they can be. This probably does not answer
your concern sorry, but this is all I could think of ;)

Originator: YES

> thank you for the example files, they will be useful in the future. I am
sorry but I cannot check with sumatra pdf (I am working on a mac) but
apparently latex treats the pdf file correctly because its position in the
resulting pdf does not seem to take in account the object outside the page,
only the

True. And that is what prevented me from discovering this "feature" for so
long. Although I was always wondering why the .pdf file come out so large
from inkscape.

> page itself. displaying objects outside the bounding box is a
feature indeed, but should only be activated when the user asks for it
(such as selecting the display of the media box, bleed box or such). Are
there such options in sumatra PDF viewer?

no, you have no choice here. Sumatra is extremely simple piece of
software. It has almost no options at all so far. But it is extremely fast,
I havn't seen a faster pdf-viewer for windows that this one yet.

> As for the export in Inkscape, it would indeed be very nice to have as
much flexibility in vector export that in raster export (export only page,
only selection, etc. You could search for a RFE about this and add one if
necessary, that would be welcome).

sure

> However, discarding some parts of a vector drawing would probably have
to be done by clipping/masking it and
this is also non desctructive (the clipped part are not displayed any more
but are still there).

I doubt that masking is a good idea. Exporting to .pdf, .eps, .emf
presumes that the image is prepared for publishing or displaying. I usually
work on the whole project in a single source file, and then export the
needed parts by moving them to the page area or just highlighting these (if
vector editor is capable of exporting the selection). Thus I expect that
the rest of the file is excluded. By including all the masked objects you
make the file very large without reason.

> If one wants to actually suppress everything outside
an area, this has to be done via boolean operations and their results are
non trivial as soon as there are some complex, self intersecting paths that
would have to be cut by these operations. You can try them from Inkscape
currently and see how difficult they can be. This probably does not answer
your concern sorry, but this is all I could think of ;)

So apparently you are mostly concerned about the objects that are
partially within the page area. Well, here the masking might work, because
I do not expect the file to grow that much because of couple pieces
sticking out.

However, I think this is the option that is actually rarely needed. At
least I do not remember a single case when I would not crop my drawing
myself but expected the editor to do this for me at export. Anyhow, the
option I am missing the most is "Export Selection". So I think as a baby
step, this can be implemented the first.

A related RFE (request to export only the drawing, which should hopefully be easier than all this clipping business) is at https://bugs.launchpad.net/inkscape/+bug/171511

I have the feeling that I was not clear enough with my request. Let me fix it.

These days the term "project" become quite popular. All powerful text editors/IDE can do projects, search among the files in a project etc. Guess what, inkscape does not do projects. But this is not needed, because the concept is already there. Before I started doing what I am doing now I spend some time in graphical design/publishing business. You will be surprised, but very few people working with vector graphics editors there have one picture/drawing/diagram per file. In fact, most of the time all the stuff for the current project is kept in one file and whenever you need to print any particular piece you just move it to the "paper area" and send it to printer. Whenever you need to process or forward a piece further you select it and choose "export selection". Thus, it is done in other commercial applications, therefore it is doable and there is a reason for that. Inkscape already does something similar, but in case of .pdf it does it in a quite strange way. So all I am requesting is to make "export selection" available for all types of exported vector formats and make the output file to contain only the items it is expected, without all tricks with masking the rest of stuff by the crop box.

And I think that https://bugs.launchpad.net/inkscape/+bug/171511 is very slightly related to current request.

Yes, there seems to be consensus that the most desirable feature would be the ability to 'export selection' to PDF. I'll update the bug title to reflect this. Can I ask how would you want this to interact with the current document's page size? I can think of a couple ways this could work:

1) the document's page size is ignored, and the output PDF is tightly cropped to the selection, even if they are off the page. This would be equivalent to calling 'resize page to selection' right before the export.

2) the page size of the output PDF is specified by the document's page size, but only the selected objects are included in the file. If the selection is off the page, they are invisible. (Unless you use Sumatra, apparently :) )

Tom,

It is my understanding that you are talking about the new subitem "Export selection" in the File menu, right? It is just that in current state Inkscape does not have the "Export" item, but the export to the formats other than .svg is done through "Save As...". I am using the release version 0.45, so I apologize if it is already different in some latest builds. Anyhow, if you add such item then the total list of choices will be something like:

Save
Save As...
Save As Copy...
Export <-- this one has to be here if the next one is in the list.
Export Selection
Export Bitmap

seems like too much choice, as for me.

Anyhow, none of two ways you presented seem perfect to me, so I offer the third one, combining them.

3) All the exporting is done either through the "Save As" menu (as it is now) or through separate "Export" menu (for all formats except .svg?). For the formats that support the "page size" parameter, the following takes place:

 (a) if a selected object is detected in the current document, the checkbox "[X] Export Selection" becomes active, and it is already checked. In case the user realizes that he accidentally left that object selected, then by clearing the box he has a chance to fix it and the page size of the output file will be specified by the the documents page size. If there is any object sticking out of the page margins the, user is warned by a popup window with the choice to automatically "Fix it" by adjusting the paper size, or to "Cancel" the process and return to the document to fix it manually.

 (b) if there is no selected object, the page size of the output file is specified by the document's page size with the exception described above.

You decide whether the "[ ] Export Selection" appears in the "Save As..." dialog by default and becomes active when needed, or it just popups in separate dialog (to attract more attention?).

Obviously, I offer this way just because I already saw it elsewhere, and it works. It might not be perfect solution, so it is subject for discussion.

As to Sumatra Viewer. I almost forgot how all this started. Disrespect to the cropbox of the .pdf file is definitely a bug, but I am grateful the developer for this "bug", otherwise I would have never realized why my PDFs generated from LaTex come out so humongous.

To all the affected people: I would suggest trying a newer version of Inkscape, available at :
http://sourceforge.net/projects/inkscape/files/inkscape
the latest version is 0.47pre3

It has a export area is page option for PDF (File->Save as...). Please test.

> It has a export area is page option for PDF (File->Save as...). Please
> test.

The "problem" stays the same as before. The export area is just
clipped to the page but the objects out of the page are still present
in the file (which was actually already the way things were working
before). To test that you can create a document with an object outside
of the page, save it as PDF and:
- view it with a PDF viewer: you'll only see the blank page
- re-open it with Inkscape: you'll see the blank page and the object
outside of the page

That said I am not sure this is a bug. This is actually the way PDF
works: there are several boxes: media box, crop box, art box etc.
which contain objects. You usually only see the crop box, which
corresponds to the physical page, but objects outside of the page can
be used for other purposes: cropping marks, color scales etc. So they
need to stay there.
What Inkscape would need is a way to define theses boxes. But I don't
think they have an equivalent in SVG, or maybe in SVG print but
Inkscape is currently not focused on that.

Sorry then. As a matter of fact I've used that option but hadn't throughly tested it. I know is the way PDF works with is multiple boxes (media, trim, etc.) but an option to crop *on export* would work wonders for very big projects. Although I don't personally use, as I avoid having large quantities of objects around that are not going to export anyway.

Mr. Korneta: Could you explain why do you have so many objects outside the page area? wouldn't moving those objects to a hidden layer avoid exporting them? (I'm just asking because I don't know if hidden layers are exported or not to PDF!).

Regards.

> Could you explain why do you have so many objects outside the page area?

Mr. Trabajos, in fact I did mention this in one of the posts above, but anyway. it has to do with the way I'm used to work on a big projects involving vector graphics (picked up the habit a while ago working as a graphics designer and now keep using preparing the diagrams for scientific papers ). There is a bunch elements which are drawn with a reference to each other, a bunch of service shapes and object which are meant to help in the process but not to be included in the final graphics. More that that, there are lots of copy-paste elements between the different figures so I simply keep all the figures of the project in one inkscape document, moving them to the page area when it is time to export. Thus, I was very frustrated to find that all my exported figures have the same size, which essentially is the size of the total document, and the extra elements are even visible in certain pdf-viewer.

My life would be a lot simpler (and I believe many users would support this) if there was a choice to export selected objects only into vector formats, the way _it is possible to export into bitmap formats currently_. Means that the bounding box is set to the smallest area including the object of interest no matter whether it is on the page area or not. It also means that the objects outside of selection are not included in the exported document in any form, neither hidden nor exposed (I have a feeling that I'm repeating here what was said in some of the posts above).

> wouldn't moving those objects to a hidden layer avoid exporting them? (I'm just asking because I don't know if hidden layers are exported or not to PDF!).

probably, I don't know. Never had this idea, will need to test this later today. If it works, it would be a workaround to solve my problem. But you have to understand, the reason I posted this report in the first place is simply because I'm used to have this functionality in all other major commercial vector graphics editors I worked with, so I see this are essential feature and not as idiosyncrasy of particular user.

> Mr. Trabajos, in fact I did mention this in one of the posts above, but anyway.
Excuse me if my question seems repetitive or reiterative. Rest assured that whenever I take part in a report it's because I read the messages before. I just need to know the details of user's workflows so I can amalgamate a solution in my brain. The problem, as I see it, is that there are three kinds of cases were the user would want to export only parts of the whole document (this is a hodge-podge of what everyone said):
1* Several graphics inside a file: Like having many finished graphics ready for exporting to different output files. For instance: you've a file 2009_party_flyers.svg, which is a project containing many finished artworks related to a party, and you need to export areas of it to different PDF files: 2009_party_flyers-3x2in.pdf, 2009_party_flyers-A4.pdf, 2009_party_flyers-4x5in-b&w.pdf, ... In Illustrator this is called Artboards. With this approach the concept of *one* and only one page doesn't exist anymore as there are multiple "pages" inside a file. Exporting to PDF one of these regions would export only objects in it and the bounding box applied would be the size of each region. Your comment #14 about "projects" seemed to go in that direction.
2* Graphics outside the page area for work but not output: Many people have work-in-progress copies of graphics they place later on the page, either as a copy or a clone. I do this continuously. I play a lot outside of the page before starting compositing the drawing on it. It's a playful way to develop and experiment without the risk of messing the main artwork. Users would want to export only the page area (and avoid everything outside).
3* Exporting just a selection: Only the selection is exported with the bounding box as the page size. It has been mentioned along this report too.

Your comment #14 made me think that you would benefit from case 1*, while comments #16 and 20# seemed to point to case 2*. There my confusion and why I reiterated the question on my comment #19.

Of course, this is not directly related to your problem, Mr. Korneta, as all three points above will need from a "do not include objects outside of area of interest in PDF"; and this should be an option as some users want to keep them while others might not. When I see reports with many user experiences I try to develop a multilateral solution and thus I've to ask a lot ;).

Now my 2 cents:
Ideally, a slicing tool should be integrated into Inkscape that could set "export areas" (like in case 1*), with the option to export outside objects or not. The layout of options in the PDF export dialog would be:
* Export area: page, whole drawing, selection or slice X.
* Keep objects outside of export area: yes|no
* (Rest of options are kept).
This would cover case 1*, 2* and 3*.
The slice tool would be the same for bitmap exporting for webs.
(I know this last part is a bit sketchy, like how to interact with it or store the slices and those insignificances ;) ).

Regards.

> Excuse me if my question seems repetitive or reiterative. Rest assured that whenever I take part in a report it's because I read the messages before.

my apologies for this one, I did not mean to be rude or something, just pointed out.

> 1*
> 2*
> 3*
> Your comment #14 made me think that you would benefit from case 1*, while comments #16 and 20# seemed to point to case 2*. There my confusion and why I reiterated the question on my comment #19.

I say I'd benefit from all 3 cases. Lets say I almost never have a document in which I want all the graphics to be exported. Just want to point out that in case 3* the bounding box better be the size of the exported graphics, not the size of the page, if the graphics if outside the page.

> Of course, this is not directly related to your problem, Mr. Korneta, as all three points above will need from a "do not include objects outside of area of interest in PDF"; and this should be an option as some users want to keep them while others might not. When I see reports with many user experiences I try to develop a multilateral solution and thus I've to ask a lot ;).

when exporting to .pdf one already has the pop-up window asking about pdf version and converting text to paths. So why not to include there a checkbox "Include the objects outside the bounding box [ ]" (cleared by default, obviously)

> Now my 2 cents:
> * Export area: page, whole drawing, selection or slice X.

I didn't ask for slice and can't think about any personal usercase, so I abstain from discussion.

Thanks for your reply ;)

> Just want to point out that in case 3* the bounding box better be the size of
> the exported graphics, not the size of the page, if the graphics if outside the page.
Yes, I agree.

> I didn't ask for slice and can't think about any personal usercase, so I abstain from discussion.
That part was more oriented to the developers. Eventually I will do a blueprint based on user cases like yours. The PDF export dialog is lacking some important features like this one.

One more question: do you use Illustrator's artboards?

Regards.

> One more question: do you use Illustrator's artboards?

I never used Illustrator in my work, unless there was an emergency. I'm more like Freehand (I'm still missing it) and CorelDraw guy. So -- no, I do not use the artboards.

> when exporting to .pdf one already has the pop-up window asking about
> pdf version and converting text to paths. So why not to include there a
> checkbox "Include the objects outside the bounding box [ ]" (cleared by
> default, obviously)

My guess is "because it is not trivial".

With pixels it is easy: render everything, crop, throw away pixels out
of the crop box and you are done.

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. But then what about an object outside of
the page but which blur comes inside of the page? What abut a master
object outside of the page but which LPE transformed form comes inside
of the page? What about a group that has elements both inside and
outside of the page? One would need to dismantle the group, remove the
object(s) that are outside and recreate the group afterwards. The
theoretical simplest solution would be to perform a boolean
intersection operation between all objects of the drawing and an
object which has the size of the page. However, try using bool ops ob
complex paths and you'll soon see that is it far from straightforward.
Often when the path is altered, the inside becomes the outside, some
nodes become isolated etc. Even with a perfect bool op routine, this
might still affect the look of the drawing: blurs might not look the
same, LPEs either etc.

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 behaviour you want to suppress (i.e.
retaining objects outside of the page). Every other software that I
can think of works this way at least. 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!

I am not saying that it won't happen. I am just trying to put your
issue in a more general context.

JiHO
---
http://maururu.net

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...

wouldn't it possible, to add a special property to every object: "include in pdf... yes|no" or similar ?
and additionally (if possible to implement) a message like "check objects outside of..." when I want to save e.g. as pdf?

then I could do it as I want it to be done by hand.

just my 2 cents

p.s. my problem was, that I - too - thought, that a picture, that I put outside the page-area wouldn't be included in my pdf-file - and wondered about the huge pdf-file... :-) .

vonHalenbach wrote on 2007-12-10:
> Changed in inkscape:
> assignee: nobody → jiho
> status: New → In Progress

@JiHO - are you actively working (or plan to work) on implementing this feature request? Else I propose to revert the assignee to nobody and the bug status to 'Triaged' or 'Confirmed'.

Setting Status back to 'Confirmed' since there has been no activity code-wise to implement such a feature. Please revert if this was done in error.