eps export always sets bounding box to drawing, never to whole canvas

could you specify which viewer you are using?

the behaviour is dependent upon the viewer: if I generate two images, 'drawing.eps' and 'canvas.eps' both based on the same original image, and if I view them in GSView32 then both images are displayed on the same size of page, which in my case is letter size. The difference between the two images is that the canvas.eps image is located at the expected original position in the page, while the drawing.eps image has been translated to the origin at the bottom left, as expected.

If I import these two images into Microsoft Word then both images behave as if they were 'drawing', not 'canvas', as indicated in your report.

However, the two bounding boxes are different:
the canvas.eps has a bounding box given by:
%%BoundingBox: 56 475 533 746
while the drawing.eps has a bounding box given by:
%%BoundingBox: 0 0 476 271

note that the size of the box is the same in both cases, but the box has been translated as expected.

Your comment is completely right.
I am using gsview32 4.9 + ghostscript 8.64.
The behavior of the viewer is as expected. The eps doesn't contain page size information, so gs displays it on whatever a page size is currently set in gsview.
Importing the eps into another program will in most cases clip the drawing to the bounding box, as you noted for MS Word.

So, as the eps doesn't (and shouldn't) have page size information, if one really wants the drawing to have the size of the canvas, the bounding box should be set to the size of the canvas.

The EPS Specification requires that the "bounding box is the smallest rectangle that encloses all the marks painted".

http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf Section 2.1.

<quote>The EPS Specification requires that the "bounding box is the smallest rectangle that encloses all the marks painted".</quote>

This contradicts the eps export option "whole canvas".
Taking your comment serious, there would be no choice of "whole canvas", i.e. the choice between the eps export option "drawing" and "canvas" could be completely removed from inkscape.
I don't see any serious reason for keeping this option choice. The effect of adding a white margin to the drawing could better be achieved by adding a white rectangle in the background of the drawing, which would be automatically respected by the bounding box.

    there is a fundamental, and deliberate, difference between the two options as they are currently implemented. The 'canvas' option preserves the original absolute coordinates of the objects while the 'drawing' option does not, it instead translates everything to the origin at (0,0). This leads to distinctly different behaviour when viewing the file, as it should.
     I think this is behaving at it was designed to behave, and I don't think this is a bug.

It isn't a bug in the strict sense, but I think it is misleading.
The difference between the eps files generated with the two options makes no difference when importing the eps into another application (which is the purpose of an eps file). The eps specification quoted by Adrian Johnson explicitly requires the importing application not to take into account the absolute coordinates but only the coordinates relative to the bounding box. So the option "whole canvas" is misleading because it makes me think that the eps when imported into another application will include the whole canvas while in fact it will not. So the option "whole canvas" should either specify a bounding box of the size of the whole canvas (breaking the eps specification in the strict sense but producing a result which I would expect) or be completely omitted.

OK, it may be a matter of taste whether the option "whole canvas" as it is currently implemented is useful. For me it isn't. I suggest to end the discussion until having heard other peoples' opinions on this.

In Inkscape 0.46, the "Save As.." EPS option "Make bounding box around full page" works as expected.

In Inkscape 0.47pre2 (r22153, built Sep 10 2009), any combination of the "Save As.." EPS options "Export area is drawing" and "Export area is page" do not produce the same result. An examination of the generated EPS file suggests that there is no bounding box around the full page.

Please somehow support the old functionality.

Thanks.

Files that illustrate the problem are attached.

The EPS specification is requires that the bounding box be the smallest rectangle enclosing all marks on the page. The 0.46 behavior was a bug.

If your really want the bounding box to be the whole page you can draw a white line (assuming your page color is white) around the page.

The "bug" in 0.46 was very handy because it meant I didn't have to draw the white box--I could just use the page size.

The inclusion of the "bug" in 0.46 meant Inkscape automated something for me that I would otherwise have to do manually--the very thing computers and software are best at doing.

Please consider restoring the *OPTION* for the useful non-specification compliant behavior.

Thanks.

What application are you using that requires a page sized bounding box?

The two applications that I use for testing the import of cairo EPS output, Latex and OpenOffice, only import EPS files correctly when the bounding box is compliant with the specification ie a tight bounding box.

Hi, I just updated my Inkscape 0.46 to 0.47 and I was totally disappointed with the new behavior of Save as .eps. I extensively use Inkscape for drawing pictures for my publications in LaTeX and use Oni's svg2tex extension (http://github.com/Oni/svg2tex) to export text layer with math formulas as .tex file which than includes .eps file with the drawings as background.

Problems I have:
One problem with 0.47 is that bounding box is put around drawing (since all text objects are on the hidden layer when I save .eps file) in .eps and all texts in .tex document are relative to page origin (0,0).
The second problem is that in .tex file \includegraphics comand has height and width parameters for drawing it wants to produce which are equal to the page size in Inkscape (I think this is correct behavior), so my imported .eps file is expanded and text positions are not matching those I wanted to be.

These to points make it almost impossible to workaround the issue except putting a colored rectangle equal to the page size, which I think you Adrian would also agree is far from ideal solution, e.g. page with gradient background.

Moreover, specification "The EPS specification is requires that the bounding box be the smallest rectangle enclosing all marks on the page." does not say what "mark on the page" is. In my case empty space between page border and the nearest object is also mark on the page and I want it to be in my finat .eps file.

OK, there is quite easy workaround:

Export .eps with "Export area is page" checked. Then go to Document Properties and in Customize size choose pt as Units and remember Width and Height values. Then open your exported .eps file with some text editor and modify %%BoundingBox and %%PageBoundingBox to have values 0 0 your_page_width_in_pt your_page_height_in_pt.

That's it. This is ugly and not what one wants but it works for the moment (or for ever if it stays in the status of not wanted feature).

BTW thanks for the great software.

I can't understand the problem you are having with importing EPS files into LaTeX. I've tested the EPS export with both LaTeX and OpenOffice. I get correct results if the bounding box is tight. If I make the bounding box the size of the page the figure is mostly empty space with a tiny drawing in the middle.

I'm attaching my LaTeX test case.

And my EPS file. The text "A4 Portrait" refers to the original page size it was created with. When exported to EPS cairo has set the bounding box to the extents of marked areas of the page.

This is the output from running:

latex document.tex
dvips document.dvi

The figure is correctly sized in the document.

This is the output I get if I change the bounding box in the EPS file to the page size. ie

%%BoundingBox: 0 0 595 842

Clearly the figure is the wrong size in this output.

I created a LaTeX example with the 'wish' behavior and two cases when .eps exported with "Export area is drawing" and "Export area is page", respectively. You see that last two figures are the same (except 2pt on width and height added to the bounding box in case "Export area is page" is chosen), .eps is upscaled and text appears in wrong positions.

You might as why I do so? This is because some figures might be used in more than one paper which are submitted to different journals which on their side use different fonts. If I integrate text into svg, then I need to update text and formulas fonts for each of them, if I use .tex and compile textual information together with the drawing, then all fonts and their sizes match paper font.

One more thing, If you you check Option->EPS Clip in gsview32, then you see that both "Export area is drawing" and "Export area is page" drawings look the same (again except 2pt on width and height added to the bounding box in case "Export area is page" is chosen) and I guess this is what most applications see when you import .eps file.

With 0.47 it's impossible to export an eps with the whole page. The box around the eps is related to the image in all cases! Check the example in attachment.

Yes, that's what this bug report is about, but Adrian Johnson and probably other developers do not agree that that setting bounding box to the whole page should also export image with page sized box. Seems like from their point of view bug was in the previous versions of Inkscape.

If I check the option "Export area is page" from a drawing with a little image in middle of an A4 page for example, then I expect an eps with the size of an A4 page with a little image in middle. Why is this checkbox option existent, but without effect (I have compared both generated eps bitwise, with and without "Export area is page", result: exactly the same file aside from date)??

Two options:
1. Remove this checkbox option from export dialog (not favored)
2. Add a transparency or white box with page size to the exported eps automatically

Workaround:
Use the PS-export! Here the option "Export area is page" does what it must do!

related to available options in the export dialog:
Bug #499965 "exported area is the drawing" and "exported area is the page" aren't alternative in export

I totally agree that being able to set the bounding box to the whole page is a useful feature in EPS export (one I inadvertently used often until I upgraded to 0.47), albeit one that isn't supported officially by the EPS specification. I appreciate the "bug" in 0.46 needed to be fixed, but can you add some workaround option in later versions? Thanks all for the tips on a manual workaround.

Adrian Johnson wrote:

>> The EPS Specification requires that the "bounding box
>> is the smallest rectangle that encloses all the marks painted".

Nonsens. The specification not "requires" that!! You can read in chapter 2.1 only: "For an EPS file, the bounding box is the smallest rectangle that encloses all the marks painted on the single page of the EPS file". Every eps applications all over the world accepts a bigger bounding box than the image is...

I am the creator of the image and and I want say: "A white border of 5 mm is a essential part of my image"....

That's exactly what I tried to say in my #12 post, but somehow this was not heard. I also agree that I am the one who determines what is a part of the image and what is not but definitely not the software bug.

The option "Export area is page" behaves as expected with PS or PDF but not with EPS. In my opinion, no matter what the EPS standard requires, this option should behave the same way for the three formats.
Would it be a reasonable compromise to have two options as follows?

1. "Export area is page" corresponding to the old the Inkscape 0.46 behaviour
2. "Export area is page (strictly standard compliant)" corresponding to the current behaviour

Best regards.

I agree with #25, #26, and #27.
Because it should be possible to have white around an image, exporting "area is page" should work like it does for PDF. This has nothing to do with the EPS-standard imho. Because one could argue that the white area around some black stuff should also deliberately be 'drawn', the bbox definition in the standard is ambiguous.

"Export area is page (strictly standard compliant)" is a very confusing name. Moreover, when would this behavior be desired, and what extra does it offer above "export area is drawing"?
I propose to revert "export area is page" behavior to 0.46 and 0.45.1 behavior ("make bounding box around full page").

(yes, 0.45.1 and 0.46 behave the same, probably the anomaly is 0.47.)

inkscape devs: the PS and EPS exporting is identical, except for telling cairo that EPS should be outputted instead of PS.

I have asked about this on the cairo maillist, but the answer was discouraging.
If you really need to use EPS instead of PS of PDF, I advice to find out how to file a bug with cairo and nag them about it.
The relevant maillist thread: http://lists.freedesktop.org/archives/cairo/2010-July/020250.html

A patch has been supplied that adds a feature to cairo to remedy this bug. I don't know how to proceed, hopefully the patch will be in the new cairo version, until then, I guess we have to #ifdef cairoversion the solution.

Good news and thanks for your efforts. Could the fix or some workaround make into 0.48?

> Good news and thanks for your efforts. Could the fix or some workaround
> make into 0.48?

Very probably not. (workaround: save as PS and rename to EPS)

The patch has been pushed to git master. When the next cairo development snapshot is released you should be able to do something like:

  surface = cairo_ps_surface_create()
  #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 11, 2)
  if (override_bbox) {
    cairo_ps_dsc_comment(surface, "%%BoundingBox: 100 100 200 200");
    cairo_ps_dsc_begin_page(surface);
    cairo_ps_dsc_comment(surface, "%%PageBoundingBox: 100 100 200 200");
  }
  #endif

to override the generated bounding box.

Awesome, so it will be in Cairo 1.11.2? (the devlibs for windows now contain cairo 1.8.8)

I added code to cairo-render-context.cpp to do exactly what Adrian said in #34. Let's review if this works when Cairo 1.11.2 is released.

Cairo 1.11.2 has been released so this feature should work now.

I think 1.10.2 is the latest stable release? So at least for 0.48.1, this bug will still be present.

Yes 1.10.2 is the latest stable. Anyone who can't wait for 1.12.0 can build 1.11.2.

I have a slightly different angle to this bug: I often make additional drawings, notes, discarded objects etc which I push outside of the canvas. This is also impossible in eps export since everything appears in the exported eps file. Interestingly, Gsview shows the correct bounding box (equal to the canvas), but draws the other objects around it as well. The same happens if I include this file in TeX and view the dvi output.

On the other hand this might mean that this is also a bug in gsview and the dvi viewer.

A half-decent workaround for me is the creation of a second layer where I put all excess stuff and then hide it for export.

You can't just copy the code into cairo-render-context.cpp. You need to define override_bbox and set the bounding box dimensions yourself. The code does not compile as is so I am going to comment it out.

Wow, I just copied it without changing it? That's amazingly dumb, sorry for that.
Hope to fix it soon.

When you fix it you will need to add the "cairo_ps_dsc_begin_page" line from my example to ensure the page level comment is inserted in the correct location.

Just committed a fix, can you test if it compiles Tav (uncomment the stuff) and commit it ? Thanks!
Also, does it fix the bug?

The BoundingBox/PageBoundingBox DSC comments must be integers. So you will need something like:

   os_bbox << "%%BoundingBox: 0 0 " << (int)ceil(width) << (int)ceil(height);
   os_pagebbox << "%%PageBoundingBox: 0 0 " << (int)ceil(width) << (int)ceil(height);

hmm, so why are the width and height parameters to "cairo_ps_surface_create_for_stream" of type double?

Because PostScript allows floating point coordinates. So there is no reason to restrict the cairo surface size to integers.

If you are inserting DSC comments directly you need to be familiar with the DSC specification to ensure your DSC comments conform to the specification. %%BoundingBox is documented on page 39 of
http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

See also the notes about a conforming document on page 17.

unassigning myself. i do not want to spend time reading about something that people in this thread obviously can tell us too, to fix this fast.

I read the whole discussion, and I am unable to decide whether we should strictly respect or not the EPS specifications. Nonetheless, I faced the problem of having my text and graphics unaligned while exporting to EPS+LaTeX. A solution is to export to PS+LaTeX or PDF+LaTeX but a publisher was asking for EPS only. Thus I used the following trick: I export to PS+LaTeX, use ps2eps to change my PS file to EPS, and change manually the BoundingBox according to the BoundingBox in the PS file. Note that as I need the PS file, it is quicker to only export in PS and then use ps2eps than exporting in both PS and EPS. Then I also have to change my .ps_tex file. This yields the following bash script. It is to be used after exporting file.svg to file.ps and file.ps_tex. It takes as only argument file.svg.

#! /bin/bash

file=${1%.svg}

ps2eps $file.ps

# Copy BoundingBox from ps to eps
# /!\ This does not respect EPS specifications, but this /seems/ to work with LaTeX

bb=$(grep "^%%BoundingBox:" $file.ps | cut -d: -f2 | cut -d" " -f2-)
bb1=$(echo $bb | cut -d" " -f1).000000
bb2=$(echo $bb | cut -d" " -f2).000000
bb3=$(echo $bb | cut -d" " -f3).000000
bb4=$(echo $bb | cut -d" " -f4).000000
sed -i -e "s/^%%BoundingBox: .*/%%BoundingBox: $bb/" -e "s/^%%HiResBoundingBox: .*/%%HiResBoundingBox: $bb1 $bb2 $bb3 $bb4/" $file.eps

# Change the file.ps_tex

mv $file.ps_tex $file.eps_tex
sed -i -e "s/\(\\includegraphics.*\){$file.ps}/\1{$file.eps}/" $file.eps_tex

Thanks Bruno for the work around in form of a bash script.
I'll check it out.

I'm also working with LaTeX (The last people who are interested in eps?). And for me a tight bounding box is not desirable.
In my work flow sketches from BKchem (0.13) are converted from .svg with Inkscape to .eps to stuff them into my LaTeX-files.
BKchem set's the canvas to (tightboundingbox + 10 px) in each direction automatically. That's perfect.
Even if this should not be clean eps, I'd like an option to force a bounding box bigger than the drawing itself. Inkscape is free to warn me about that.

So, if this is not a bug, is it a feature request?
Perhaps someone could enlighten me: Does the code of Cairo need to be changed for that? (There was a discussion about that in this thread, but I just didn't get what the result was.)

I just want to emphasize, why I need the bounding box to be bigger than the drawing:
In chemistry, especially chemical drawings, empty space carries information!
Mostly meaning: There is nothing attached to that atom at that place.
This is important if you place two drawings side by side in a document.
Imagine two drawings having chemical symbols at the same height, one at the right edge of the canvas, the other on the left edge of the canvas.
When there is no space at the edges of the canvas and those drawings are put side by side, the two chemical symbols count as connected by a chemical bond, because there is no space in between them.
The bad thing is: Sometimes this connection makes sense and the error is not obvious at a first glance.

I'm chiming in to say this bug affects me too.

I need to have transparent space around my EPS exported drawings because I use them for overlays in LaTeX (beamer) presentations. For example, suppose I am showing a diagram step by step, such that a box in the diagram appears in the first slide, the second slide adds another box, the third another one, etc. Obviously in the first slide I need to leave empty space for the boxes that will appear later. So what I typically did was work with a fixed canvas in Inkscape, so everything would align nicely. This is not possible now.

I am aware of the workaround of adding white elements where I want the edges of the image to be, but this is not really satisfactory, as it has several problems:
1. They can get in the way when doing mass selections and moving things, leading to a disaster (unwillingly changed the bounding box).
2. If the background of the slides is not white, I have to hunt for the exact color (and transparent elements won't work, Inkscape seems to detect and just remove them).
3. If I want to re-use the EPS figure for another presentation with a different background color, I can't. I have to change the SVG, re-export it, etc.

In short, there are use cases (and this is an example) where this change in Inkscape results into a serious loss of functionality.

I have read the debate above on the EPS specification. I'm not really an expert on that specification so I won't comment on whether it really forces the bounding box to fit to the drawing or not. But even if it does, I think that shouldn't prevent Inkscape from keeping the useful "fit to the canvas" functionality. I can think of at least two different solutions:

- Give the option but, when enabling it, show a dialog warning the user that the option is against the strict EPS specification and that the user chooses it at their own risk.
- Make the exporting process draw two very small white dots coincident with the upper left and lower right coordinates of the canvas, so that the specification would be followed to the letter. These dots would be in the EPS file but not in the SVG (as it would be something implemented in the export function). Note that this is worse than the previous solution because it solves points 1 and 3 but not 2, but I propose this in case the developers want to be puristic and not let the user go against the specification even at their own risk.

It is quite common to want transparent space around the contents of an eps. In particular, I agree with Carlos Gómez Rodríguez regarding beamer presentations.

At the very least, inkscape should respect the presence of transparent rectangles when setting the eps bounding box.

Here's another regular use-case for exporting images:

  1. Stick the JPEG image in a separate layer
  2. Image the image.
  3. Export the rest of the page (textual content) page as PDF
  4. Hide the rest of the page contents layer
  5. Unhide the image layer
  6. Export the JPEG image (only) to an .eps
  7. Hand-hack the image-only.eps %%BoundingBox to be 0 0 842 595
  8. epstopdf on the exported image-only.eps EPS
  9. pdftk image-only.pdf background rest-of-page.pdf output both.pdf to get a sensibly compressed/sized accessible PDF.

Step 7. should be unnecessary given I've ticked the box saying the BoundingBox should be the page!

Interestingly Inkscape 0.91 (on Win7) draws bounding boxes smaller than the complete figure if the inkscape page is smaller than the drawing and "Use document's page size" is chosen during export.
I'm not sure if this OK with the eps standard.
Basically I think the deal is that EPS dows not have a "%%DocumentMedia: 56x31mm 158 88 0 () ()" comment in the standard.
And we (want to) use the BoundingBox as an replacement for that.
But for reasons of an easy workflow I'd vote for "ignore the spec" and warn the user that this might not be 100% to the spec.

Maybe it is time to change to pdf files in the LaTeX workflow...

I created Bug #1524870 "EPS export does not respect "Bleed/margin (mm)" setting" which is related to this bug:
I'm not sure when it was introduced, but Inkscape 0.91 has a "Bleed/margin (mm)" setting for the Postcript exports. But it's not working for eps. Because, well... a margin is empty whitspace which is not included in the bounding box, as discussed here.

The issue still exists in 0.92.2

Interestingly, when exporting to ps, both output page size options (1. Document's page size, 2. Exported object's size) work as expected. But, for eps, only the drawing is exported irrespective of the option chosen in dialog.

There are use cases for exporting the whole page with the white space around the drawing. The page size is specifically chosen depending on where the image is going to be used and the drawing is usually carefully positioned within the page. So, exporting whole page should capture this placement of drawing in the page. It works this way in PNG, ps. There's no reason it shouldn't work in eps.

Here is an svg file along with ps and eps exports with different export area options.

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

The issue was reported in https://gitlab.com/inkscape/inbox/-/issues/2205 (from another bug migration), and I've left a comment summarizing the issue in https://gitlab.com/inkscape/inbox/-/issues/2205#note_390572782 You can +1 the issue or turn on notifications in GitLab to follow the discussion.

Please feel free to file new bugs about the issues you're seeing at http://inkscape.org/report.