Bounding box too small in EPS export

Bug #186182 reported by Arnt Richard Johansen
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
Unassigned

Bug Description

Steps to reproduce:
1. Create a new document with a polygon. Choose a high value for the stroke width.
2. Save a copy of the document as .eps.
3. Open the EPS file in a viewer (I tried Evince and KPDF, which give the same result)

Expected result:
The EPS image should contain the entire polygon.

Actual result:
The miters of the polygon overflows beyond the edge of the image.

It seems that Inkscape disregards the stroke width and assumes that all polygons are infinitely thin when deciding which part of the canvas should be part of the EPS export.

Revision history for this message
Arnt Richard Johansen (arj) wrote :
Revision history for this message
Arnt Richard Johansen (arj) wrote :
Bryce Harrington (bryce)
Changed in inkscape:
importance: Undecided → High
status: New → Triaged
importance: High → Medium
Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

bbox issue is fixed

there's another issue now - unclosed path in lower right corner, see bug 168129

Changed in inkscape:
status: Triaged → Fix Released
Revision history for this message
su_v (suv-lp) wrote :

re-opening: this issue is still present in Inkscape 0.46+devel r22498 on OS X 10.5.8.

Paths with stroke style 'join' set to 'miter' exceed the (visual) bounding box and get cut off when exporting to bitmap or EPS.
(first reported in bug #166659)

Changed in inkscape:
status: Fix Released → Confirmed
tags: added: stroke ui-selection-group-layer
Revision history for this message
su_v (suv-lp) wrote :

marking as duplicate of Bug #166659 in Inkscape: “Bounding box does not include long miters”: <https://bugs.launchpad.net/inkscape/+bug/166659>. If you don't agree please add a comment and revert the duplicate status.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

Is this really the same bug as 166659? This bug is for EPS export while 166659 is for PNG export. The EPS bounding box is calculated by cairo. I'm assuming Inkscape calculates the PNG bounding box.

Can you attach the current EPS output? The sample output in comment 2 was from before Inkscape switched to using cairo for generating EPS.

Which PostScript viewers are being used to check the EPS output?

Does the miter clipping occur if other objects are adding to force the bounding box to be larger? An incorrect
parameter specified for the setmiterlimit PostScript operator or a PostScript viewer bug can also cause clipped miters.

Revision history for this message
su_v (suv-lp) wrote :

'Triangle.svg' exported to EPS with Inkscape 0.46+devel r22528 on OS X 10.5.8

viewers used:
- Apple's Preview.app: clipped left, top, right
- gv (gv 3.6.7) (BBOX): clipped left, top, right
- gs (GPL Ghostscript 8.70 (2009-07-31)): clipped on the left side

Revision history for this message
su_v (suv-lp) wrote :

'Triangle.svg' exported to PDF (export setting: drawing [x])
with Inkscape 0.46+devel r22528 on OS X 10.5.8

Revision history for this message
su_v (suv-lp) wrote :

Note: I get the same results whether I use the visual bounding box or the geometric bounding box setting in Inkscape. The exported object is clipped with the visual bbox - identical to the bbox boundaries you see on-canvas in Inkscape with visual bbox mode.

Similar to bitmap export Inkscape seems to always use the visual bbox for export to PDF/EPS?

Revision history for this message
su_v (suv-lp) wrote :

screenshot comparing Inkscape bbox boundaries and gv displaying EPS exported from Inkscape.

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

The Bounding box in the EPS file is incorrect. If you edit the file to increase the size of the %%BoundingBox and %%PageBoundingBox comments the miters are not clipped. Viewing the file directly with ghostscript also works since it is gv/evince/Preview that is interpreting the DSC comments, not gs.

The bounding boxes in the EPS file are generated by cairo so initially this did look like a cairo bug. But the bounding box is never larger than the page size so if Inkscape sets the cairo PostScript page size too small when creating the EPS file the bounding box will be too small. Looking at the PDF output this appears to be exactly what is happening.

There is a another problem. The triangle is positioned to far to the bottom left resulting in the bottom left being clipped because it is off the page. This is the fault of Inkscape. It looks like Inkscape is trying to position the bottom left of the triangle at (0,0) but incorrectly calculates the extents of the triangle.

Moving the drawing to (0,0) is not necessary in EPS files. The bounding box DSC comment specifies the lower left and upper right corners of the bounding box so that the application importing the EPS can correctly position the drawing.

The solution for EPS output is for Inkscape to avoid trying to set the page size to the drawing extents or moving the drawing to (0,0). Cairo will set the correct bbox and it will all just work.

For PDF, cairo does not currently calculate or provide any way to specify the bounding box so I can understand why Inkscape would want to move the drawing to (0,0) and limit the page size to the bounding box to ensure the PDF can be correctly imported into other applications. The problem is Inkscape is incorrectly calculating the drawing extents resulting in the bbox too small and the drawing incorrectly positioning. This problem is the same bug as 166659.

Cairo has a new function that will help with calculating bounding boxes - cairo_meta_surface_ink_extents(). But this is not yet in any stable release. It should be in 1.10 when it is released.

Revision history for this message
su_v (suv-lp) wrote :

Thank you for the prompt analysis! Unfortunately bug #166659 looks close to 'Won't fix" (comment #3) for now until Inkscape completely switches to a Cairo based renderer (I am not a dev - but AFAIU this is still part of the roadmap's 'Medium term goals').

Revision history for this message
Adrian Johnson (ajohnson-redneon) wrote :

The EPS bug can be easily fixed by creating the cairo PS surface with the full page size instead of the drawing extents and not translating the drawing to (0,0). Cairo will do the right thing when creating the %%BoundingBox comment.

For other export types that use cairo, Inkscape only need to wait for cairo 1.10 which has the new recording surface. Completely switching to cairo rendering is not required. Then is just a case drawing to the recording surface, getting the extents of the recording surface, create the output surface (pdf etc) and paint the recording surface onto the output surface.

Revision history for this message
su_v (suv-lp) wrote :

Removed the duplicate link that I previously set without taking into account that export routines to EPS(/PS/PDF) could set the BoundingBox independently from Inkscape's bbox calculation.

Revision history for this message
su_v (suv-lp) wrote :

Changing status to 'Triaged' because the detailed comments by Adrian Johnson should give any interested developer enough hints how to improve EPS export and let cairo calculate the correct bounding box size.

Changed in inkscape:
status: Confirmed → Triaged
tags: added: cairo eps exporting
removed: stroke ui-selection-group-layer
Revision history for this message
su_v (suv-lp) wrote :

PDF/EPS export of 'drawing' area seems fixed in revision 9307.

Revision history for this message
su_v (suv-lp) wrote :

Attaching the EPS instead of the PDF file - viewing it with Preview.app and Ghostview no longer shows cut-off miters.

su_v (suv-lp)
Changed in inkscape:
milestone: none → 0.48
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.