Skip to content

Make importers aware of bottom left coordinate system - #635

Open
t-oster wants to merge 1 commit into
masterfrom
feature-633-import-bottom-left
Open

t-oster wants to merge 1 commit into
masterfrom
feature-633-import-bottom-left

Conversation

@t-oster

@t-oster t-oster commented Jan 19, 2022

Copy link
Copy Markdown
Owner

In #633 @LaFabrique35 suggests, that if the lasercutter has a bottom-left coordinate system, the files should be placed relative to the bottom left.
E.g. if you have this SVG:

example.zip

the rectangle is positioned x=20 and y=30 (relative to the bottom of the view box).

I started implementing this, but I have a few things to consider:

  1. Is this what all users would expect? The SVG file itself has the coordinate system always top left as dictated by the SVG standard, but the position where the SVG viewbox is placed on the laserbed is changed.
  2. What about the G-Code importer? Should we interpret all Y-Coordinates in the G-Code as relative to bottom left (is anyone using the G-Code importer anyway?)
  3. Should the Raster-Importers (JPG,PNG etc) import the drawing also bottom-left?

Binaries are at https://download.visicut.org/feature-633-import-bottom-left

@LaFabrique35

LaFabrique35 commented Jan 20, 2022

Copy link
Copy Markdown

Wow, what responsiveness! This new proposed version works very well! I was able to test it with the users of my FabLab, it works really well! Thank you !

EDIT : Going deeper into the tests, it seems that the bottom left move only works half the time. When this does not work, a "CSS implement" error appears.

@t-oster
t-oster requested a review from mgmax February 4, 2022 07:08
@mgmax

mgmax commented May 9, 2022

Copy link
Copy Markdown
Collaborator

Sorry for the long delay, I was busy with other stuff :-)
It is certainly good for the one original user request, but I'm not sure about how this fits as a general solution.

Looking at the code: My feeling is that we're slightly mixing up the interface boundaries. In an ideal solution, we would separate between

  • "import the file and remember the page size" (convert SVG/JPG/whatever to PlfPart. Store the page size in some property, if the format has some definition of page size. GCode does not. JPG is always "page size = image size".)
  • "move it to the bottom corner" (PlfPart.moveToBottomLeft() ?)
  • decide whether to move to the bottom corner (separate checkbox for preferred position ?)
  • configure where the zero point in the GUI ruler should be.

At least it would be nice to keep this y-shifting out of the individual image importers, or to the very least rename the method arguments from "originIsBottomLeft" to "placePageAtBottom"

Regarding functionality, I'm still struggling to fully understand the use case. I don't think that the position of the origin is crucial. The origin is artificial and doesn't matter for how you use the lasercutter. Maybe the position of the physical "ruler" where you physically align your rectangular piece of material is more relevant: If your cutter only has that on bottom-left, then (without VisiCam camera view) you will prefer to push your material against that corner for repeatable positioning.

@mgmax mgmax left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs discussion, see my previous comment from a long time ago

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants