Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export canvas x / y offset is inverted #523

Closed
ghost opened this issue Dec 3, 2019 · 7 comments · Fixed by #708
Closed

Export canvas x / y offset is inverted #523

ghost opened this issue Dec 3, 2019 · 7 comments · Fixed by #708
Labels
Milestone

Comments

@ghost
Copy link

ghost commented Dec 3, 2019

System information

  • SolveSpace version: 3.0~690f87c
  • Operating system: Debian 9.x stretch (x86_64)

Expected behavior

Export canvas x / y offset should be relative to left-bottom x / y position.

Actual behavior

Export canvas x / y offset actually is inverted (really it should be -x / -y, as actually positive increasing offsets move export canvas origin to down-left direction)

pic.1

Additional information

For bugs, please attach a savefile that shows the problematic behavior.
You can attach .slvs files by archiving them into a .zip first.

@whitequark whitequark added the bug label Jan 23, 2020
@whitequark whitequark added this to the 3.0 milestone Jun 23, 2020
@phkahler
Copy link
Member

@Symbian9 is this right? It seems like the offset should be relative to the canvas origin. If you export with no offset it would place things at the edge of the canvas, so you'd want to use a positive offset within that coordinate system. At least that's my interpretation which could be wrong. Same thing when 3d printing, I have to tell the slicer where my print-bed corner is relative to the home position of the printer - which would look a lot like this and requires positive offset values.

@ghost
Copy link
Author

ghost commented Jun 25, 2020

is this right? It seems like the offset should be relative to the canvas origin.

Yes.

@phkahler, on my screenshot above lower left corner of rectangle ("visible entity") placed at the canvas origin (by "Center View At Point").

But if set "export canvas size: fixed" and set "offset x/y" properties to positive values, "export canvas" window (construction rectangle on screenshot) moved to ⭹ direction (instead of expected moving to ⭷ direction).

So, actually exported "visible entities" moved according offset values instead of expected moving "export canvas" window.

SOLUTION: Switch internal calculated positive values of "offset x/y" properties to negative values only for "export canvas size: fixed" option.

@phkahler
Copy link
Member

So here is a picture. I created a 50x40 rectangle with the lower point at the origin. I exported as svg and opened that at the top. It's hard to see the purple because there is no background. The X and Y offsets work exactly as I expect. The rectangle is 20 from the left of the SVG origin and 5 from the bottom - as specified in the export offset values. I also confirmed that 0 aligns with the left side for X offset and bottom for Y. I honestly don't see any problem here.

I also tried exporting G-code, but it didn't seem to be affected by these settings - the point coordinates were 0, 40 , and 50. I have not tried any other export options. As far as I can tell these settings are not visible in any way on the SolveSpace sketch and I would not expect them to be. @Symbian9 Can you be give a better example of the problem? Perhaps a simple .slvs and an exported file that behaves incorrectly?

export

@ghost
Copy link
Author

ghost commented Jun 25, 2020

The rectangle is 20 from the left of the SVG origin and 5 from the bottom - as specified in the export offset values.

But for "export canvas size: fixed" option the "offset x/y" should be relative to the canvas origin.

This is NOT "paper margins" (as it defined for "export canvas size: auto" option).

FTR, If actual "export canvas size: fixed" option "offset x/y" internally calculated as bottom/left margins, I request change this behavior to calculate "offset x/y" relatively to the canvas origin (only for "export canvas size: fixed" option).

OR add option to select how calculate its origin via radio buttons:

  • 🞊 "by absolute dimensions and left/buttom margins" (as it actually works)
  • 🞅 "by absolute dimension and offset from canvas origin"

@phkahler
Copy link
Member

I tried one as "auto" and it seems to work as indicated "(by margins around exported geometry)" where the exported SVG contains only the actual geometry plus margins as specified.

export2

That example was not at the origin and I think I get what you're after.

When you say "for "export canvas size: fixed" option the "offset x/y" should be relative to the canvas origin." do you mean the solvespace sketch origin? Do you want to specifiy in SS coordinates the lower left corner of the exported area and its width and height?

I'm trying that and getting really confused. To get this:
export4

I had to specify negative offsets, which works kind of like I expected. The geometry was offset by the amount specified. What you want is for the -6 and -24 to be positive 6 and 24 is that correct? If so, I would suggest that the wording not be "offset" but "coordinates" of the exported area. Weather that warrants another option I don't know.

What I found really disturbing is that even with the negative numbers it didn't work either until I centered the view on the sketch origin. I don't think the view should have any influence on the exported image. IMHO this behavior is not discoverable or up to interpretation of wording about coordinates and offsets. The only reason I even tried it is because @Symbian9 indicated doing so in the original problem statement here.

I hope I've clarified more than confused anyone reading.

@ghost
Copy link
Author

ghost commented Jun 25, 2020

When you say "for "export canvas size: fixed" option the "offset x/y" should be relative to the canvas origin." do you mean the solvespace sketch origin?

No, I mean working space canvas origin (as defined in "Center View At Point" option).

phkahler added a commit to phkahler/solvespace that referenced this issue Sep 16, 2020
@phkahler
Copy link
Member

@Symbian9 Can you verify this change does what you want for this issue?
https://github.com/phkahler/solvespace/tree/issue523

It's just the last commit: phkahler@d94cfad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants