Pattern control handle outside of page causes incorrect bounding box when exporting to EPS.

Bug #1269627 reported by leila bridgeman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Triaged
Medium
Unassigned
Inkscape Devlibs
Triaged
Medium
Unassigned

Bug Description

I am using Inkscape 0.48 on a Windows 7 64-bit OS.

I encounter this problem when I save a drawing as an EPS and the export area I've selected includes a figure with pattern fill. If the handles controlling that object's pattern are outside the area, then the bounding box of the EPS figure grows to include the handle. This could be considered logical behaviour, and not a bug, when I select 'Export area is drawing,' but this also occurs when I select 'Export area is page' and the handles lie outside the page. (Even with 'Export area is drawing' selected, I'd expect to export the visible objects, and not have this handle effect the export area, but I see how this is debatable.)

Here is how I produce this error:
 - Open a new document (I chose Default type)
 - Draw a rectangle inside the page with the 'Create rectangles and squares' tool (Alternately, draw a shape with the bezier tool).
 - In the 'Fill and Stroke' interface, give the shape a pattern.
 - Use the node tool to move the pattern handles off the page.
 - Use 'File\Save as' to save as EPS. In the dialogue, select 'Export area is page.'
 - Open the Eps. You will see that the exported area was not the area indicated by the page borders in Inkskape; it has grown to include the handle.

A second possible bug that I encounter that worsens the problem is that if I have previously changed the pattern control handle position for an object and then 'resize the page to fit drawing or selection' the handle teleports to somewhere else, often outside the area indicated by the page borders.

Here is how I produce this error:

 - Return to the previous Inkscape document.
 - Select the object you drew with the node tool.
 - Return the handles to somewhere on the page area.
 - In the Page tab of the Document Properties dialogue, click 'Resize page to drawing or selection. You will see the pattern handles jump to a new position on the page.

I hope my description is helpful!

-Leila

summary: - Pattern control handles outside of page causes incorrect bounding box
+ Pattern control handle outside of page causes incorrect bounding box
when exporting to EPS.
Revision history for this message
su_v (suv-lp) wrote :

Reproduced on OS X 10.7.5 with:
- Inkscape 0.48.2 and cairo 1.10.2
  (official latest Inkscape package for OS X, 32bit)

Not reproduced with local builds on OS X 10.7.5 (64bit, newer versions of cairo):
- Inkscape 0.48.2 and cairo 1.12.2
- Inkscape 0.48.4 and cairo 1.12.2, 1.12.16
- Inkscape 0.48+devel r13050 and cairo 1.12.2, 1.12.16

Looks like a bug triggered by older versions of cairo (<= 1.12) - Inkscape packages for Windows use cairo 1.11.2, and thus would be affected by this too.

tags: added: cairo eps exporting
Revision history for this message
su_v (suv-lp) wrote :

@JazzyNico - do you happen to have local Windows builds (stable or trunk) which use a newer cairo version, and could test whether the incorrect EPS page size still occurs with current cairo on Windows?

su_v (suv-lp)
tags: added: pattern
Revision history for this message
jazzynico (jazzynico) wrote :

@~suv -I'm sorry I can't find a way to reproduce the bug. All the Inkscape versions I've tested so far (0.48.2 with Cairo 1.10.2, and 0.48.3.1, 0.48.4, trunk revision 13122, all three with 1.11.2) export the pattern as expected. I'm probably missing something obvious...
Could you attach and SVG file and two EPS showing a wrong and a right export please?

#Leila - Could you please give your exact Inkscape version (top right of the Help>About dialog)?

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

@JazzyNico: sample SVG and EPS file taken from a identical report on irc, see attached zip.

$ grep %%BoundingBox squinky86-doubleslit_gun*.eps
squinky86-doubleslit_gun-0482-cairo-1_10_2.eps:%%BoundingBox: -140 -1 253 670
squinky86-doubleslit_gun-0482-cairo-1_12_2.eps:%%BoundingBox: 0 -1 253 271
squinky86-doubleslit_gun-0484-cairo-1_12_14.eps:%%BoundingBox: 0 -1 253 271
squinky86-doubleslit_gun-0484-cairo-1_12_2.eps:%%BoundingBox: 0 -1 253 271
squinky86-doubleslit_gun-048x-r10012-cairo-1_12_16.eps:%%BoundingBox: 0 -1 253 271
squinky86-doubleslit_gun-048x-r10012-cairo-1_13_1.eps:%%BoundingBox: 0 -1 253 271
squinky86-doubleslit_gun.eps:%%BoundingBox: -140 -1 253 670

Revision history for this message
jazzynico (jazzynico) wrote :

@~suv - Thanks for the files and the grep. Ghostview doesn't give a correct view of the bounding box if you don't open the information dialog...

Confirmed on Windows XP, Inkscape 0.48.4 and trunk revision 13122 (cairo 1.11.2).
Not reproduced with an experimental revision 12282 with cairo 1.12.8.

> Looks like a bug triggered by older versions of cairo (<= 1.12) - Inkscape packages for Windows use cairo 1.11.2, and thus would be affected by this too.

Exactly!

Changed in inkscape:
status: New → Triaged
importance: Undecided → Medium
Changed in inkscape-devlibs:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
leila bridgeman (leilabridge) wrote :

@~ jazzynico - My version is 0.48. (That's all I see in Help>About in the 'Splash' tab, but that's what I have in the original bug report, so I'm not sure what more details you want. Sorry!)

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.