redteam316
commented
9 years ago Can you supply a sample file showing this?
Using data doesn't sound like a good idea because the word is so generic.
Open forresto opened 9 years ago
redteam316
commented
9 years ago Can you supply a sample file showing this?
Using data doesn't sound like a good idea because the word is so generic.
forresto
commented
9 years ago <svg width="640" height="480" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg">
<g>
<ellipse ry="100" rx="100" cy="200" cx="200" fill="#FF0000" data-fill-type="standard01" />
<ellipse ry="100" rx="100" cy="200" cx="200" stroke-width="5" stroke="#000000" />
<path d="m160,187c-1,0 -95,50 -95,50c0,0 428,-8 428,-8c0,0 -85,-40 -85,-40" stroke-width="5" stroke="#000000" />
</g>
</svg>Thinking to use standard fill, stroke for color differentiation, and order for layering. Then, when we need to attach more info (how to fill or stroke), use attributes like data-fill-type.
redteam316
commented
9 years ago I think I understand what you are trying to do now. Is there a solid filling pattern that you plan on using other than tatami? The idea is that fills are a solid singular color (the svg spec even does this). Gradients and what we are going to be calling "hatch patterns" are covered under the linearGradient, radialGradient and pattern elements in the SVG spec ( http://www.w3.org/TR/SVG/pservers.html ).
I think creating a list of all stitch fill types should be done first before getting too deep into this. Tatami would be 1.
forresto
commented
9 years ago Yeah, thinking to start with solids, and simple zigzag for path thickness.
I guess with tatami you could have data-fill-angle as well? Cool to learn the terminology (I'm sleeping on tatami these days).
So does libembroidery handle the conversion from SVG to various machine formats, or is there another level? I'm a bit desperate to design some PES files for our new 4x4 Brother. :smile:
forresto
commented
9 years ago Also relevant standard properties: ‘stroke-linecap’ and ‘stroke-linejoin’ http://www.w3.org/TR/SVG11/painting.html#StrokeLinecapProperty
redteam316
commented
9 years ago libembroidery does handle conversion to and from SVG and machine formats. Currently there are some things that need fixed or implemented for SVG though. If you plan on generating your patterns programmatically, using the CSV format is the best route but SVG would work too. If you plan on designing something in Inkscape for example, you're going to run into several issues unless you use the inkscape extension I hacked together which resides in the experimental folder and even then it has a few problems( @stesie appears to tweaked it some but I haven't seen a pull request yet ).
The API changes to libembroidery I made earlier should allow the Inkscape extension to be modified to output any format using libembroidery (I just haven't tested it yet) It should fix several issues with the python bindings as well as other language bindings, but breaks the delphi binding (sorry @x2nie).
The fill angle and possibly x/y offsets is the only other data I think that would be needed for a proper svg extension. Like I mentioned previously, I think using the word data is too generic. If you look at how Inkscape adds their own data into an SVG file, you will see sodipodi and inkscape littered throughout the file, so using embroidery-fill-angle or possibly a more brief emb-fill-angle would be best for that type of approach.
Try converting any embroidery file into an SVG and you will see that our SVG writer produces raw polyline output. That output is much more suitable for a machine or viewing in other apps but is not suitable for easy editing, so do you propose making these new extensions available under an "Embroidermodder SVG" versus a "Plain SVG"? If it is possible to have both work when being present in the same SVG file, I would prefer that, but I'm not sure if it's possible.
x2nie
commented
9 years ago no worry when delphi binding broken. I think current delphi binding is proof of concept, it doesn't yet do nothing than convert from one to other embroidery format. I can fix-up it later. Thanks you.
forresto
commented
9 years ago It would be awesome to make a web-based svg path/pattern editor, then use https://github.com/Embroidermodder/Embroidermodder/tree/master/experimental/javascript to directly make binaries to copy to the machine. I'd be into building a proof-of-concept.
Have you tried the emscripten port recently?
redteam316
commented
9 years ago Forrest, I haven't tried the emscripten port for awhile, but I tried it tonight to refresh myself on where it was at. The libembroidery-convert-js shell script works fine for outputting the basic usage, but our error handling reports that it's not able to open files for reading, so that's where it is at.
See the output below(I just commited a few minor changes upstream for emscripten stuff):
$ ./compile-js
temp/emb-time.c:38:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
1 warning generated.
$ ./libembroidery-convert-js
_____________________________________________________________________________
| _ _ ___ ___ _____ ___ ___ __ _ ___ ___ ___ _ _ |
| | | | | _ \| __| | _ \| _ \ / \| | \| __| _ \ | | | |
| | |_| | _ <| __| | | | _ <| /| () | | |) | __| / |__ | |
| |___|_|___/|___|_|_|_|___/|_|\_\\__/|_|___/|___|_|\_\|___| |
| ___ __ ___ _ _ _ ___ ___ _____ |
| / __|/ \| | | \ / | __| _ \|_ _| |
| ( (__| () | | | |\ \/ /| __| / | | |
| \___|\__/|_|___| \__/ |___|_|\_\ |_| |
| |
| * Emscripten Version * |
|_____________________________________________________________________________|
| |
| Usage: libembroidery-convert fileToRead filesToWrite ... |
|_____________________________________________________________________________|
_____________________________________________________________________________
| |
| List of Formats |
|_____________________________________________________________________________|
| |
| 'S' = Yes, and is considered stable. |
| 'U' = Yes, but may be unstable. |
| ' ' = No. |
|_____________________________________________________________________________|
| | | | |
| Format | Read | Write | Description |
|________|_______|_______|____________________________________________________|
| | | | |
| .10o | U | | Toyota Embroidery Format |
| .100 | U | | Toyota Embroidery Format |
| .art | | | Bernina Embroidery Format |
| .bmc | | | Bitmap Cache Embroidery Format |
| .bro | U | | Bits & Volts Embroidery Format |
| .cnd | | | Melco Embroidery Format |
| .col | U | U | Embroidery Thread Color Format |
| .csd | U | | Singer Embroidery Format |
| .csv | U | U | Comma Separated Values Format |
| .dat | U | | Barudan Embroidery Format |
| .dem | | | Melco Embroidery Format |
| .dsb | U | | Barudan Embroidery Format |
| .dst | U | U | Tajima Embroidery Format |
| .dsz | U | | ZSK USA Embroidery Format |
| .dxf | | | Drawing Exchange Format |
| .edr | U | U | Embird Embroidery Format |
| .emd | U | | Elna Embroidery Format |
| .exp | U | U | Melco Embroidery Format |
| .exy | U | | Eltac Embroidery Format |
| .eys | | | Sierra Expanded Embroidery Format |
| .fxy | U | | Fortron Embroidery Format |
| .gc | | | Smoothie G-Code Format |
| .gnc | | | Great Notions Embroidery Format |
| .gt | U | | Gold Thread Embroidery Format |
| .hus | U | U | Husqvarna Viking Embroidery Format |
| .inb | U | | Inbro Embroidery Format |
| .inf | U | U | Embroidery Color Format |
| .jef | U | U | Janome Embroidery Format |
| .ksm | U | U | Pfaff Embroidery Format |
| .max | U | U | Pfaff Embroidery Format |
| .mit | U | | Mitsubishi Embroidery Format |
| .new | U | | Ameco Embroidery Format |
| .ofm | U | | Melco Embroidery Format |
| .pcd | U | U | Pfaff Embroidery Format |
| .pcm | U | | Pfaff Embroidery Format |
| .pcq | U | U | Pfaff Embroidery Format |
| .pcs | U | U | Pfaff Embroidery Format |
| .pec | U | U | Brother Embroidery Format |
| .pel | | | Brother Embroidery Format |
| .pem | | | Brother Embroidery Format |
| .pes | U | U | Brother Embroidery Format |
| .phb | U | | Brother Embroidery Format |
| .phc | U | | Brother Embroidery Format |
| .plt | U | U | AutoCAD Plot Drawing Format |
| .rgb | U | U | RGB Embroidery Format |
| .sew | U | | Janome Embroidery Format |
| .shv | U | | Husqvarna Viking Embroidery Format |
| .sst | U | | Sunstar Embroidery Format |
| .stx | U | | Data Stitch Embroidery Format |
| .svg | U | U | Scalable Vector Graphics |
| .t09 | U | | Pfaff Embroidery Format |
| .tap | U | | Happy Embroidery Format |
| .thr | U | U | ThredWorks Embroidery Format |
| .txt | | U | Text File |
| .u00 | U | | Barudan Embroidery Format |
| .u01 | | | Barudan Embroidery Format |
| .vip | U | | Pfaff Embroidery Format |
| .vp3 | U | U | Pfaff Embroidery Format |
| .xxx | U | U | Singer Embroidery Format |
| .zsk | U | | ZSK USA Embroidery Format |
|________|_______|_______|____________________________________________________|
| | | | |
| Total: | 48 | 22 | |
|________|_______|_______|____________________________________________________|
| |
| http://embroidermodder.org |
|_____________________________________________________________________________|
$ ./libembroidery-convert-js KDE.EXP TEST.DST
ERROR: format-exp.c readExp(), cannot open KDE.EXP for reading
ERROR: libembroidery-convert-main.c main(), reading file KDE.EXP was unsuccessfulThere likely needs to be a little Emscripten C code magic that needs to be implemented into the EmbFile functions but I'm not quite sure what needs to happen yet. SDL2 recently added Emscripten support to their library so I will eventually dig into how they implemented file reading/writing and also see if there is an official way that Emscripten might suggest to use so that we can determine the proper fix.
I would really like to see your proof-of-concept because I feel that in the future, using Emscripten for the javascript binding is really the way to go.
forresto
commented
8 years ago https://github.com/evil-mad/robopaint is web-based (electron shell) and quite advanced for
... could make a mode within Robopaint that uses their work and outputs CSV. Then we just need a working convert.js to output the formats needed.
tatarize
commented
8 years ago It would be in error to attempt to modify the given SVG format. SVG specification gives a variety of different methods to extend the SVG format and use that extendability for non-standard elements and foreignObjects within a switched context. I'm currently authoring a different embroidery program for Android (Touch Embroidery) which works natively with SVGs but is hitting a roadblock with how to describe the higher level elements without including them directly in the SVG.
So, I've thought a lot about this. The biggest problem is that the embroidery formats are a clusterfrack. Some include various bits of information that are completely pointless others include different pointless data others include sometimes shape data other-times images in various thread colors from a magic list. So there's all this data which is going to be lost if you save into a format that is less powerful than you can currently describe. If you have a DST file, that might as well be a compiled file binary because you have some start and stop data (cuts are a weird -2,-2,+4,+4,-2,-2 stitch thing) but there's no color data or the higher level data and some like .EMB include this stuff but it's certainly not open. So really extending SVG to not only do the path data (which is great) but to basically be the core format for embroidery. Without this things are a lot more difficult to save your progress and reload accordingly.
The proper format would be something akin to:
<switch>
<foreignObject width="100" height="50"
requiredExtensions="http://touchembroidery.com/SVGExtensions/Embroidery">
<ellipse ry="100" rx="50" cy="50" cx="25" fill="#000" stitch-fill="tatami" stitch-angle="40" underpathing="centered" thread="Isacord 20 Black" />
</foreignObject>
<ellipse ry="100" rx="50" cy="50" cx="25" fill="#000"/>
<polyline stroke="#000" stroke-width="3" points="[actual-stitches of a tatami filled ellipse]/>
</switch>This is a valid and actually open format (an SVG Extension here is needed) and would allow max compatibility and power (it would need to do everything any embroidery format does and more).
Opening this in say Inkscape would read the foreign object has a non-standard requiredExtension skip that and then do the ellipse because it understands that. Many direct readers could then skip the ellipse object and find a polyline object which is certain to be directly able to be converted into stitch data.
Viewing this in a compatible embroidery program would see the tatami filled ellipse at a 40° angle with centered underpathing made with Isacord thread. An svg reader would see the black ellipse and show that to the user (a pretty good representation mind you). And a quick and dirty svg to stitches converter could well just access the stitch data from the polyline object, and feed that to whatever clusterfrack of proprietary embroidery formats that is required.
The trick here then is to determine a goodly set of acceptable and useful embroidery fills and objects and then map those out. The original question has one, but that's not actually anywhere near the amount of ways to fill in a even a circle. Not only can you do radial fills but guilloches with multiple colors. There's significant utility in having a fill that does a normal back and forth pattern but steps down two lines each time. This would allow your fill area to be a loop and have no need for underpathing, as geometrically loops can just be pasted into another set of lines etc.
tatarize
commented
8 years ago But things like "Gradients and what we are going to be calling "hatch patterns" are covered under the linearGradient, radialGradient and pattern elements in the SVG spec" this is not what the SVG spec is covering, it covers actual gradients. You want to extend a foreign object that defines a specific hatch-pattern type and applies that to a shape.
You're going to be left scratching your head if you keep trying to just use the graphics elements in SVG as some kind of secret handshake code for embroidery when they aren't. It needs an SVG extension which stores that actual data in a very understandable and usable format which directly allows reuse and valid fully realized descriptions of the actual objects. Then when you save, you save them in a switch tag which saves the embroidery object, the graphics svg object, and the stitch data.
Then the program can very well load up an SVG and then show the graphics. Then a given embroidery program can modify that to give it specific instructions on how those lines are filled in, and what they look like filled in. Describing the fill and any modifications to the fill pattern, and producing stitch data from those settings which are also saved in the file that can be rebuilt when things are resized etc.
So you'd end up with gradients objects that draw on graphics objects and crosshatch objects that draw on embroidery objects and the stitch data all in the same file AND in valid SVG format.
tatarize
commented
7 years ago Also, while neither here nor there. Having mapped a lot of the math out, tatami is not a fill pattern. It's an algorithm. Well, it's a class of algorithms which fill in an object with some kind of proper fill (zig-zag, z, E, parallel lines) and connects the non-monotone parts of the given polygon/shape through (typically) underpathing.
Fills are built on smaller bits, typically a proper fill would be how map out a space filling curve, into a given envelope, and the mathematical restrictions this engenders. For example a satin stitch is often a sweepable fill of an object in zig-zag, with turn corrections. So it only works in sweepable polygons. Whereas a flat fill is typically parallel boustrophedon pathing in a monotone shape. Such shapes are by definition sweepable, but not all sweepable polygons are monotone. But, really both typical fills flat and satin are properly fills. And if one misses this, and supposes that tatsumi is a type of fill and basically the fill they utterly miss the point. And fall into the same errors of traditional embroidery software.
A really proper system would break down a tatsumi fill into the sequences of flat fills and underpathing that it actually is, thus allowing a person better access, control, and the ability to more or less maintain the same rendering of the embroidery objects at a higher level even if the implementation of tatsumi locally does not exist or would path objects completely differently.
Would it be possible to make simple svg extension that would just add
data-to describe color and fill? Then you could open/preview/draw the files anywhere, and convert them with EmbMod.