cont

RESOURCES/doc/tutorial.html

@@ -711,10 +711,11 @@ <h4>LibreCAD <span style="color:#008000">****GOOD****</span></h4>
 concatenation of lines/arcs with beziers/splines into a single SVG path, but it
 is fixable per hand in the output.</strong></p>
 
-<p>Conclusion: <strong><span style="color:#008000">A good SVG "path" generator/exporter
-that is unfortunately not completely finished.</span></strong></p>
+<p>Conclusion: <strong><span style="color:#008000">A good SVG "path"
+generator/exporter that is unfortunately not completely
+finished.</span></strong></p>
 
-<h4>SolveSpace <span style="color:#ff00ff">****BEST****</strong></span></h4>
+<h4>SolveSpace <span style="color:#ff00ff">****BEST****</span></h4>
 
 <p>Ever heard of it? A parametric system as known from the 3D modellers.
 <strong>Incredible!</strong> The GUI looks like from the beginning of the '80s,
@@ -786,12 +787,19 @@ <h4>What else?</h4>
 <h3>Conclusion</h3>
 
 <p>The fact that it is so difficult to find an acceptable SVG path "writer"
-program can only be due to the SVG format itself, which is completely "user" or
-"app" un-friendly. The path definition is too complicated. What is the point of
-allowing paths with sub-paths? maybe because the SVG format completely ignores
-the concept of "multiline"/"multipolygon" etc. Polygons have no "interiors" so
-they must be defined as such in a path composed with 2 or more subpaths for
-this purpose.</p>
+program let me wonder why it is the case. And why does only
+<strong>SolveSpace</strong> perform the task correctly? Why such a capable App
+like <strong>LibreCAD</strong> fails for this task? Well in case of LibreCAD,
+it cannot concatenate splines with lines, so does the export. Maybe because the
+svg path definition is too complicated, "nobody" want to parse it, and thus in
+return is interested in exporting it right. And the apps which theorytically
+could use the SVG path as import (as SolveSpace could -let's write a patch!-)
+export them then correctly too. But who else would want to import svg paths?
+What do all these SVG apps? I cannot test them all! Concerning svg paths, what
+is the point of allowing paths with sub-paths? maybe because the SVG format
+completely ignores the concept of "multiline"/"multipolygon" etc. Polygons have
+no "interiors" so they must be defined as such in a path composed of 2 or more
+subpaths for this purpose.</p>
 
 <p><strong>All in all very desapointing, excepted <span
 style="color:#008000">LibreCAD</span> and <span

RESOURCES/doc/tutorial_standalone.html

@@ -322,7 +322,6 @@ <h3 id="P-03-04">Create the GCode</h3>
 <h2 id="P-04">GUI Components</h2>
 
 <h3 id="P-04-01">Svg Settings</h3>
-
 <img src="pycut_svgsettings.png" width="310px"> 
 
 <h4>user units scale</h4>
@@ -334,7 +333,6 @@ <h4>user units scale</h4>
 1</strong>. Note that the user units are not "px" or whatever. This means,
 <strong>1 "user unit" is equal to 1 mm (and the viewbox is "0 0 100 40" while
 width="100mm" and height="40mm")</strong></p>
-
 <img src="Inkscape_settings_mm.png" width="563px"> 
 
 <p>Of course when editing the svg (in Inkscape or in a text editor),
@@ -351,7 +349,6 @@ <h4>user units scale</h4>
 scale to 25.4</strong>. Because of this, the <strong>view box remains at "0 0
 100 40"</strong>. That way, a rectangle filling the full document size is still
 100x40.</p>
-
 <img src="Inkscape_settings_in.png" width="563px"> 
 
 <p>Filling a box half the size of the document is 50x20, right, but what are
@@ -424,7 +421,6 @@ <h4>user units scale</h4>
 <p></p>
 
 <h3 id="P-04-02">Tool</h3>
-
 <img src="pycut_tool.png" width="310px"> 
 
 <h3 id="P-04-03">Tabs</h3>
@@ -436,7 +432,6 @@ <h3 id="P-04-03">Tabs</h3>
 effective, the tabs have to be enabled and of course placed somewhere on the
 generated toolpaths. The height of the tabs is shared by all tabs. <strong>They
 are ignored for Pocket operations</strong>.</p>
-
 <img src="./pycut_tabs.png" width="310px"> 
 
 <p></p>
@@ -453,7 +448,6 @@ <h3 id="P-04-04">Material</h3>
 
 <p>The Operations "Cut Depth" should not be larger than the material thickness.
 </p>
-
 <img src="./pycut_material.png" width="310px"> 
 
 <p></p>
@@ -466,7 +460,6 @@ <h3 id="P-04-05">Curve to Line Conversion</h3>
 
 <p>If your design contain curves (svg "arcs" or "bezier" curves), they have to
 be discretized in small segments.</p>
-
 <img src="./pycut_curve_to_line_conversion.png" width="300px"> 
 
 <p>The 2 following parameters allow to specified how fine the curve
@@ -527,19 +520,16 @@ <h3 id="P-04-07">GCode Generation</h3>
   <li>Spindle Start/Stop (<strong>M3</strong>/<strong>M5</strong> codes)</li>
   <li><strong>M2</strong> code</li>
 </ul>
-
 <img src="./pycut_gcode_generation.png" width="310px">
-
-<!-- ----------------------------------------------------------------------------------------------------------->
 <!-- ----------------------------------------------------------------------------------------------------------->
+<!-- -----------------------------------------------------------------------------------------------------------> 
 
 <p></p>
 
 <h3>Create Operations</h3>
 
 <p>This is where the user defined its cam operations, thus this is where the
 action takes place.</p>
-
 <img src="./pycut_ops.png" width="1170px"> 
 
 <p>First one or more item(s) have to be selected in the svgviewer, click on
@@ -710,10 +700,11 @@ <h4>LibreCAD <span style="color:#008000">****GOOD****</span></h4>
 concatenation of lines/arcs with beziers/splines into a single SVG path, but it
 is fixable per hand in the output.</strong></p>
 
-<p>Conclusion: <strong><span style="color:#008000">A good SVG "path" generator/exporter
-that is unfortunately not completely finished.</span></strong></p>
+<p>Conclusion: <strong><span style="color:#008000">A good SVG "path"
+generator/exporter that is unfortunately not completely
+finished.</span></strong></p>
 
-<h4>SolveSpace <span style="color:#ff00ff">****BEST****</strong></span></h4>
+<h4>SolveSpace <span style="color:#ff00ff">****BEST****</span></h4>
 
 <p>Ever heard of it? A parametric system as known from the 3D modellers.
 <strong>Incredible!</strong> The GUI looks like from the beginning of the '80s,
@@ -785,12 +776,19 @@ <h4>What else?</h4>
 <h3>Conclusion</h3>
 
 <p>The fact that it is so difficult to find an acceptable SVG path "writer"
-program can only be due to the SVG format itself, which is completely "user" or
-"app" un-friendly. The path definition is too complicated. What is the point of
-allowing paths with sub-paths? maybe because the SVG format completely ignores
-the concept of "multiline"/"multipolygon" etc. Polygons have no "interiors" so
-they must be defined as such in a path composed with 2 or more subpaths for
-this purpose.</p>
+program let me wonder why it is the case. And why does only
+<strong>SolveSpace</strong> perform the task correctly? Why such a capable App
+like <strong>LibreCAD</strong> fails for this task? Well in case of LibreCAD,
+it cannot concatenate splines with lines, so does the export. Maybe because the
+svg path definition is too complicated, "nobody" want to parse it, and thus in
+return is interested in exporting it right. And the apps which theorytically
+could use the SVG path as import (as SolveSpace could -let's write a patch!-)
+export them then correctly too. But who else would want to import svg paths?
+What do all these SVG apps? I cannot test them all! Concerning svg paths, what
+is the point of allowing paths with sub-paths? maybe because the SVG format
+completely ignores the concept of "multiline"/"multipolygon" etc. Polygons have
+no "interiors" so they must be defined as such in a path composed of 2 or more
+subpaths for this purpose.</p>
 
 <p><strong>All in all very desapointing, excepted <span
 style="color:#008000">LibreCAD</span> and <span