The widgeting is flawed a bit in that individual elements cannot be move independently.

Raster the same image several times at different speeds for different cut times. There's no need to raster the same pixels repeatedly at the same speed. If we calculate the pixel time to burn amount based on the heat impact, we can actually get pretty significant detail overall in a couple passes.

The raster routine will at current take an image and anything greater than 127 is black etc. But, there's need for basic image manipulation within the program. It uses Pillow which will naturally have Floyd Steinberg dithering built in and can do basic operations like resizing and cropping. This might be hard to do outside of the scene. To get the DPI vs. physical size correctly setup. And the image manipulations used might be beyond basics. And scripting a good process shouldn't be too hard.

Should be able to define particular colors and have them refer to predefined known settings. To quickly allow these to be used.

The transforms shouldn't use a bunch of cryptic menu items but rather should just let you adjust the element in place. So you can drag it to the size and rotation you want. Perhaps with a button for flip horizontal or vertical.

Saving the setting is as important as setting them. Currently forgets them every time it's closed.

It's likely a typical thing that the execution of laser project will break at some point. If we still have the correct sequence we should be able to move the head to some point within the design and start from that point. So a sort of resume without knowing the current position feature. So rather than start at cut 0, start at cut 2449 moving the head to relevant position.

The execution of the Laser Job Elements works, but using the navigation to move the head will move the head but not the design. The start location for the design is still in the same location. Unlocking the rail and moving the head loses that location. And sometimes ends up being needlessly confusing without knowing where the program believes the laserhead is.

Scan the outer edge of the job before beginning. To show where it will be located.

It might actually be correct to apply the Eulerian fill algorithm to lasering. So as to rasterize the monotone parts in a more coherent way. Rather than travelling the scaffolding around the edge, we can do a direct move of the head. Since we won't be using the laser. But, There are more than a couple examples where this would be more optimal than the default methodology since traveling across a gap repeatedly could easy take more time than simply subdividing the monotone sections and rastering them individually.

Support Dxf files.

https://en.wikipedia.org/wiki/AutoCAD_DXF

It defaults to the default size but if it gives physical size make that work correctly. Too many svgs are showing up too small without the physical size scaling factors being applied.

8-bit Grayscale PNG images are not spooling to engrave.
I tested this with 24-bit colour images and they were able to spool and engrave.

Tried multiple times with an 8-bit grayscale image and

The core elements should work. It should not lack any expected features.

The main use methodologies should be have reasonable coverage. This seems to be loading a project from a set location, and reloading the same file as it's edited elsewhere. This reprioritized some elements. But, gives a straight forward roadmap.

Check for concurrency errors, or how python handles them. There may be need to add in blocks to prevent them with multiple threads running.

Control Z, shift Control Z.
Undo and Redo elements.

Etc.

" I can't say it is clear to me whether the laser is on or off. it must be absolutely clear that laser is on."
"too much colored buttons is confusing."

The svgpathtools class has the offset curve ability and I natively use the correct type of curves. It's not hard to nudge offset the curve by half a beam length in one direction or another.

nt

Ran a test SVG file and after it was done, I hit the navigation buttons and it executed those movements at the same slow speed, with the laser on, in compact mode.

K40 alignment is a newbie nightmare. It's entirely possible to help this. Since firing the laser for exact periods of time we can very slightly burn paper or burn it consistently and move in a straight line. Since mathematically what people need to do and what they don't know is that they are looking for the overlap point which is not necessarily the center point of the laser. They need to find the point where the close point (dot put on the paper/tape, etc from the home position) and the far point (dot put on the paper/tape, etc from the farest y-position from home) are the same point. For any mirror alignment this is going to be a straight line going from far point to near point then to overlap point which will be through the near point (since the beam already travelled in the wrong direction for a bit there). For the Y-axis this will be about 1/7th of the way through the beam.

So we could certainly help this if we home. Then fire a 100ms pulse, then move something like 20 increments of 10mm in the y direction for 20 ms or so. We'd know that the overlap point is through the big dot from the small dot directions. The tool itself would be a bit like the navigator tool but more concerned with running some prebuilt alignment test.

Most Wx.Widget stuff uses text icons. The icons used here should be converted as such.

The execution does not take much in the way of computing power, but because it uses the UI thread the various other windows can often stop responding. The elements are built on the idea that these processes will be non-overlapping so the UI can be updated independently. Which requires that they run in different processes.

The fire laser in control could have a very useful function if an exact duration could be set. Aligning things might get easier if we could control that aspect rather than the slop of hitting the test button.

https://forum.makerforums.info/t/laser-pulsed-control-ppi/76644

The idea is simple. We pulse modulate the beam in software. Basically we take the cut we're making and rather than just split it into plot positions, we split it into plot positions with a beam modulation value. So every 5th position or so when we said the laser should be on. We actually turn the laser on but only for that cut element. It would fire a bit like a raster line does, but while doing vector shapes and would be basically the same as PPI but in software.

There are some giant .EGV files mostly of the raster variety. It builds the loaded EGV as a path. However, the parser could also find the raster elements within the code and make those images again. This would make loading them easier as they wouldn't be prohibitively expensive to load, and could allow modifications to them that otherwise wouldn't be possible like switching from raster top-to-bottom to bottom-to-top.

Iterate through the various elements of the job counting the simple moves and the speed they are taken at to calculate the job time.

While this might be better from the get-go, there's a fairly easy system for translations in wx.Python et al. So this should be worked on after phase 2.

Feature for raster doesn't actually work.

It occurs to me that the same trick I use to do power modulation might actually work to do power modulated rastering. For example when you do 3 steps which is 333 dpi. It makes the length and width equal by stepping vertically 3 mils at the end of the raster line and within the raster line it draws pixels as 3 ons in a row or 3 offs in a row depending on the pixel state. If I don't do this but rather vary the overall power modulation, it could produce much finer details. Also, the error carried from the PPI modulation would actually matter too. It might actually look like full on regular power modulated rastering in a Stock K40 M2 Nano.

In fact, even in single step rastering this would actually just end up causing what is effectively a scanline dither. You might actually be able to just take the luma of the pixel and add it to a running total and when it exceeds max(luma) subtract max(luma) from the total and fire the laser for that pixel. This would basically result in a dither, that would apply even in stepped mode. And it would effectively cost nothing to make the image significantly more detailed.

"Also getting errors when right clicking on object over in the project tree to delete, if you don't left click first to select, then right click to delete, there is an error that pops up. I will screen grab it this evening and post if you cannot replicate."

See screenshot:

Seems like it would be more logical to have marks at rounded numbers (ie every x mm/cm)

Oshik Nissim "What I meant was if one wants a specific point on their cutter bed to be in coincidence with meerk40t 0.0 points - is there a way to move your canvas to accomplish this?"

There should be some method for doing this. And maybe have the home command return to to the new location within the bed position. So if you set a home point that is not the origin point the 0-0 for the guides is set to position from that point and homing the machine will cause it to send a HOME command, but also then move back to the home point. Usually this would be something like the upper right of the piece you'd be working on.

Might be related to #45
If Job parts or Project is selected/highlighted, right clicking on "Group" or one of the paths does not bring up pop up menu.
While mouse button is down, "project" or "job parts" selection is gone (no blue highlight anymore), but reverts to selected when mouse button is released.

When beyond phase 1. It needs a proper installer. Shouldn't require anything from the user.

Feedback and people are a must for this project so once beyond initial phase 1. Phase 2 should be getting a proper installer.

You should be able to select multiple objects and modify their settings as a group, even if they aren't themselves part of a group.

With regard to the goals to spin off the svg.path code as improved version of regbro/svg.path code. Must conduct a general audit to verify all functionality of SVG. Rectangles with Rounded Corners don't get their rounded corners, for example. And Matrix Transforms starting in SVG 2.0 will include other properties that aren't really accounted for just yet. We should support SVG 1.1 with many of the 2.0 features.

SVG must:

• Read and process all XML constructs defined in XML 1.0 and xml--names.
  *Parse any confirming XML-compatible SVG markup fragment in a manner that correctly respects the DOM structure of the content.
  • Meet all XML well-formedness constraints.
  • id attributes are valid XML IDs.

SVG graphics elements:

• Shapes straight lines and curves.
• Text
• Raster Images.

SVG Should:

• Parse all CSS syntax features defined in CSS Level 2 Revision 1.

CSS2 requires:

• Support CSS styling of SVG content including all required properties and features in Styling chapter.
  Required Properties.

Required SVG Properties.

• all properties defined in this specification

• the display, overflow and visibility properties [CSS2]

  • display="none" results in element not being rendered. Render excluded from rendering tree.
  • visibility to hidden or collapse still part of rendering tree but not painted. Inheirented.

• the cursor and text-overflow property [css-ui-3]

• the clip-path, clip-rule and mask properties [css-masking-1]

• the color and opacity properties [css-color-3]

  • Style color property is used to default indirect currentColor.
  • Property opacity <0.0,1.0>, or percentage.
  • rgb() function. Optional percentage, optional commas.
  • rgba() function, rgb with additional opacity.
  • 8 digit hex value
  • 6 digit hex value
  • 4 digit hex function
  • 3 digit hex function
  • transparent = rgba(0,0,0,0)
  • predefined basic color keywords.
  • predefined extended color keywords.
  • hsl(, percent, percent) value.
  • hsla(, percent, percent, opacity).
    • The angle value is CSS angle so deg, grad, turn, rad
  • currentColor keyword. Sets, to the value of the color keyword. Causes color inherit.

• the color-interpolation-filters, filter, flood-color, flood-opacity and lighting-color properties [filter-effects-1]

• the isolation property [compositing-1]

• the transform, transform-box and transform-origin properties [css-transforms-1]

• the letter-spacing, text-align, text-align-last, text-indent and word-spacing properties [css-text-3]

• the white-space property [css-text-4]

• the vertical-align, dominant-baseline, alignment-baseline, and baseline-shift properties [css-inline-3]

• the direction, text-orientation and writing-mode properties [css-writing-modes-3]

• the font, font-family, font-feature-settings, font-kerning, font-size, font-size-adjust, font-stretch, font-style, font-variant (along with its subproperties) and font-weight properties [css-fonts-3]

• the text-decoration, text-decoration-line, text-decoration-style and text-decoration-color properties [css-text-decor-3]

• CSS Required Features:

  • in XML documents, external CSS style sheets using the processing instruction [xml-stylesheet]
  • @media, @import and @charset rules within style sheets, as defined in CSS 2.1
  • @font-face rules within style sheets [css-fonts-3]
  • all pseudo-classes defined in CSS 2.1 (including :hover, :link, :active, :visited, :focus, :first-child and :lang)
  • the ::first-letter and ::first-line pseudo-elements defined in CSS 2.1 (on ‘text’ elements)

SVG must:

• Apply styling Styling properties to SVG content using presentation attributes.
  • Areas of an image of SVG content may have opacity less than 100%. The viewer must at least support Simple Alpha Compositing of the image of the SVG content onto the target canvas, as described in the Compositing and Blending Specification [compositing-1].
  • pathLength, stroke-array.

SVG must:

• All visual rendering must be accurate to within one device pixel or point of the mathematically correct result at the initial 1:1 zoom ratio. It is suggested that viewers attempt to keep a high degree of accuracy when zooming.
• On lower-resolution display devices, support for anti-aliasing or other smoothing methods is highly recommended. It is a requirement for conforming high-quality SVG viewers.
• If printing devices are supported, SVG content must be printable at printer resolutions with the same graphics features available as required for display (e.g., the specified colors must be rendered on color printers).
• On systems which support accurate sRGB [SRGB] color, all sRGB color computations and all resulting color values must be accurate to within one sRGB color component value, where sRGB color component values range from 0 to 255.
• SVG implementations must correctly support gzip-encoded [rfc1952] and deflate-encoded [rfc1951] data streams, for any content type (including SVG, script files, images).
• The viewer must use at least single-precision floating point for intermediate calculations on any numerical operations for conversion of coordinates.

"Use the combo of shift+wheel, alt+wheel, ctrl+wheel. Ie emulate common drawing program combos."

"Or a settings panel to switch between preset options. Ie when people see a setting they know it's an option."

Might as well. Though really, no sense burning down your house with an unwatched product.

Obviously cheating with the icon. Meerkat shooting lasers from its eyes is nice stand-in but a terrible long term branding.

The cut optimization routine would benefit from a 2-opt correction for the travelling salesman problem to minimum the cut distances overall. This should be done with and without speed changes.

Zingl Arc Plotter is a kludge. I cheated and subdivided all arcs into sets of cubic bezier curves. It's close enough nobody will notice Zingl's code runs the rotated ellipse with rational cubic bezier curves since you can weight them to exactly equal arcs. This is clearly the preferred method for plotting an arc since it properly solves for the inflection points.

Attached file (zipped because .svg is not allowed) does not size properly after import. Works in k40 Whisperer V0.27.
Had this issue with a number of other files as well.
Exported from Inkscape, document
back.zip
Inkscape document settings:

Result on import (note sizing):

Traceback:
Traceback (most recent call last):
File "MeerK40t.py", line 417, in on_click_import
File "MeerK40t.py", line 332, in load_svg
File "LaserProject.py", line 371, in svg_transform
File "svg_parser.py", line 377, in parse_svg_transform
TypeError: post_cat() takes 2 positional arguments but 7 were given

Add version information in help or window title for easier identification?

Quite a lot of buttons would benefit from a mouse over text.
Might help people find out features for themselves and lessen the amount of questions you get.

The 9/7/19 version. Currently had rastering slowly jerk around without firing the laser. It's likely not properly entering compact mode. In theory the raster mode should use the middle language for the program. So it does the v_flip and h_flip commands correctly for the raster steps. It's current system of returning positions, and the pixel value needs to be reworked for the new methods.

Before perfect it should be competent enough to let reasonably competent users test some stuff.
test-svg.zip

Bottom Up raster issues a nasty jump before starting.
The Y-axis rasters might need to be converted to vector mode edge ticking, rather than real raster mode.
If unidirectional mode was needed it would likely also need to be done this way.