embroidermodder / libembroidery Goto Github PK

{{0, 0, 0}, "Black", "002"), --> {{0, 0, 0}, "Black", ""},
{{255, 255, 255}, "White", "001"), --> {{255, 255, 255}, "White", ""},
{{255, 255, 23}, "Yellow", "204"), --> {{255, 255, 23}, "Yellow", ""},
{{255, 102, 0}, "Orange", "203"), --> {{250, 160, 96}, "Orange", ""},
{{47, 89, 51}, "Olive Green", "219"), --> {{92, 118, 73}, "Olive Green", ""},
{{35, 115, 54}, "Green", "226"), --> {{64, 192, 48}, "Green", ""},
{{101, 194, 200}, "Sky", "217"), --> {{101, 194, 200}, "Sky", ""},
{{171, 90, 150}, "Purple", "208"), --> {{172, 128, 190}, "Purple", ""},
{{246, 105, 160}, "Pink", "201"), --> {{245, 188, 203}, "Pink", ""},
{{255, 0, 0}, "Red", "225"), --> {{255, 0, 0}, "Red", ""},
{{177, 112, 78}, "Brown", "214"), --> {{192, 128, 0}, "Brown", ""},
{{11, 47, 132}, "Blue", "207"), --> {{0, 0, 240}, "Blue", ""},
{{228, 195, 93}, "Gold", "003"), --> {{228, 195, 93}, "Gold", ""},
{{72, 26, 5}, "Dark Brown", "205"), --> {{165, 42, 42}, "Dark Brown", ""},
{{172, 156, 199}, "Pale Violet", "209"), --> {{213, 176, 212}, "Pale Violet", ""},
{{252, 242, 148}, "Pale Yellow", "210"), --> {{252, 242, 148}, "Pale Yellow", ""},
{{249, 153, 183}, "Pale Pink", "211"), --> {{240, 208, 192}, "Pale Pink", ""},
{{250, 179, 129}, "Peach", "212"), --> {{255, 192, 0}, "Peach", ""},
{{201, 164, 128}, "Beige", "213"), --> {{201, 164, 128}, "Beige", ""},
{{151, 5, 51}, "Wine Red", "215"), --> {{155, 61, 75}, "Wine Red", ""},
{{160, 184, 204}, "Pale Sky", "216"), --> {{160, 184, 204}, "Pale Sky", ""},
{{127, 194, 28}, "Yellow Green", "218"), --> {{127, 194, 28}, "Yellow Green", ""},
{{229, 229, 229}, "Silver Gray", "220"), --> {{185, 185, 185}, "Silver Grey", ""},
{{136, 155, 155}, "Gray", "221"), --> {{160, 160, 160}, "Grey", ""},
{{152, 214, 189}, "Pale Aqua", "227"), --> {{152, 214, 189}, "Pale Aqua", ""},
{{178, 225, 227}, "Baby Blue", "228"), --> {{184, 240, 240}, "Baby Blue", ""},
{{54, 139, 160}, "Powder Blue", "229"), --> {{54, 139, 160}, "Powder Blue", ""},
{{79, 131, 171}, "Bright Blue", "230"), --> {{79, 131, 171}, "Bright Blue", ""},
{{56, 106, 145}, "Slate Blue", "231"), --> {{56, 106, 145}, "Slate Blue", ""},
{{7, 22, 80}, "Navy Blue", "232"), --> {{0, 32, 107}, "Nave Blue", ""},
{{249, 153, 162}, "Salmon Pink", "233"), --> {{229, 197, 202}, "Salmon Pink", ""},
{{249, 103, 107}, "Coral", "234"), --> {{249, 103, 107}, "Coral", ""},
{{227, 49, 31}, "Burnt Orange", "235"), --> {{227, 49, 31}, "Burnt Orange", ""},
{{226, 161, 136}, "Cinnamon", "236"), --> {{226, 161, 136}, "Cinnamon", ""},
{{181, 148, 116}, "Umber", "237"), --> {{181, 148, 116}, "Umber", ""},
{{228, 207, 153}, "Blond", "238"), --> {{228, 207, 153}, "Blonde", ""},
{{255, 203, 0}, "Sunflower", "239"), --> {{225, 203, 0}, "Sunflower", ""},
{{225, 173, 212}, "Orchid Pink", "240"), --> {{225, 173, 212}, "Orchid Pink", ""},
{{195, 0, 126}, "Peony Purple", "241"), --> {{195, 0, 126}, "Peony Purple", ""},
{{128, 0, 75}, "Burgundy", "242"), --> {{128, 0, 75}, "Burgundy", ""},
{{84, 5, 113}, "Royal Purple", "243"), --> {{160, 96, 176}, "Royal Purple", ""},
{{177, 5, 37}, "Cardinal Red", "244"), --> {{192, 64, 32}, "Cardinal Red", ""},
{{202, 224, 192}, "Opal Green", "245"), --> {{202, 224, 192}, "Opal Green", ""},
{{137, 152, 86}, "Moss Green", "246"), --> {{137, 152, 86}, "Moss Green", ""},
{{92, 148, 26}, "Meadow Green", "247"), --> {{0, 170, 0}, "Meadow Green", ""},
{{0, 49, 20}, "Dark Green", "248"), --> {{33, 138, 33}, "Dark Green", ""},
{{93, 174, 148}, "Aquamarine", "249"), --> {{93, 174, 148}, "Aquamarine", ""},
{{76, 191, 143}, "Emerald Green", "250"), --> {{76, 191, 143}, "Emerald Green", ""},
{{0, 119, 114}, "Peacock Green", "251"), --> {{0, 119, 114}, "Peacock Green", ""},
{{89, 91, 97}, "Dark Gray", "252"), --> {{112, 112, 112}, "Dark Grey", ""},
{{255, 255, 242}, "Ivory White", "253"), --> {{242, 255, 255}, "Ivory White", ""},
{{177, 88, 24}, "Hazel", "254"), --> {{177, 88, 24}, "Hazel", ""},
{{203, 138, 7}, "Toast", "255"), --> {{203, 138, 7}, "Toast", ""},
{{152, 108, 128}, "Salmon", "256"), --> {{247, 146, 123}, "Salmon", ""},
{{152, 105, 45}, "Cocoa Brown", "257"), --> {{152, 105, 45}, "Cocoa Brown", ""},
{{77, 52, 25}, "Sienna", "258"), --> {{162, 113, 72}, "Sienna", ""},
{{76, 51, 11}, "Sepia", "259"), --> {{123, 85, 74}, "Sepia", ""},
{{51, 32, 10}, "Dark Sepia", "260"), --> {{79, 57, 70}, "Dark Sepia", ""},
{{82, 58, 151}, "Violet Blue", "261"), --> {{82, 58, 151}, "Violet Blue", ""},
{{13, 33, 126}, "Blue Ink", "262"), --> {{0, 0, 160}, "Blue Ink", ""},
{{30, 119, 172}, "Sola Blue", "263"), --> {{0, 150, 222}, "Solar Blue", ""},
{{178, 221, 83}, "Green Dust", "264"), --> {{178, 221, 83}, "Green Dust", ""},
{{243, 54, 137}, "Crimson", "265"), --> {{250, 143, 187}, "Crimson", ""},
{{222, 100, 158}, "Floral Pink", "266"), --> {{222, 100, 158}, "Floral Pink", ""},
{{152, 65, 97}, "Wine", "267"), --> {{181, 80, 102}, "Wine", ""},
{{76, 86, 18}, "Olive Drab", "268"), --> {{94, 87, 71}, "Olive Drab", ""},
{{76, 136, 31}, "Meadow", "269"), --> {{76, 136, 31}, "Meadow", ""},
{{228, 222, 121}, "Mustard", "270"), --> {{228, 220, 121}, "Mustard", ""},
{{203, 138, 26}, "Yellow Ocher", "271"), --> {{203, 138, 26}, "Yellow Ochre", ""},
{{203, 162, 28}, "Old Gold", "272"), --> {{198, 170, 66}, "Old Gold", ""},
{{255, 152, 5}, "Honey Dew", "273"), --> {{236, 176, 44}, "Honeydew", ""},
{{252, 178, 87}, "Tangerine", "274"), --> {{248, 128, 64}, "Tangerine", ""},

Notice how: Pale Pink is properly, rgb(249, 153, 183) and not rgb(240, 208, 192).
#f999b7 vs. #f0d0c0

My guess is whoever scanned in the chart didn't pay attention that the pink there had a massive fluorescent element to it, and thus was radically wrong. I also included the catalog numbers.

You will notice that:
"{{255, 229, 5}, "Canary Yellow", ""},",
"{{250, 122, 122}, "Vermillion", ""},",
"{{107, 224, 0}, "Bright Green", ""},",
"{{56, 108, 174}, "Ocean Blue", ""},",
"{{227, 196, 180}, "Beige Grey", ""},",
"{{227, 172, 129}, "Bamboo", ""}}"

Aren't included, they aren't actually proper jef colors, if they got picked, the files would crash any proper Janome software.

Formatted:
{{0, 0, 0}, "Placeholder", "000"),
{{0, 0, 0}, "Black", "002"),
{{255, 255, 255}, "White", "001"),
{{255, 255, 23}, "Yellow", "204"),
{{255, 102, 0}, "Orange", "203"),
{{47, 89, 51}, "Olive Green", "219"),
{{35, 115, 54}, "Green", "226"),
{{101, 194, 200}, "Sky", "217"),
{{171, 90, 150}, "Purple", "208"),
{{246, 105, 160}, "Pink", "201"),
{{255, 0, 0}, "Red", "225"),
{{177, 112, 78}, "Brown", "214"),
{{11, 47, 132}, "Blue", "207"),
{{228, 195, 93}, "Gold", "003"),
{{72, 26, 5}, "Dark Brown", "205"),
{{172, 156, 199}, "Pale Violet", "209"),
{{252, 242, 148}, "Pale Yellow", "210"),
{{249, 153, 183}, "Pale Pink", "211"),
{{250, 179, 129}, "Peach", "212"),
{{201, 164, 128}, "Beige", "213"),
{{151, 5, 51}, "Wine Red", "215"),
{{160, 184, 204}, "Pale Sky", "216"),
{{127, 194, 28}, "Yellow Green", "218"),
{{229, 229, 229}, "Silver Gray", "220"),
{{136, 155, 155}, "Gray", "221"),
{{152, 214, 189}, "Pale Aqua", "227"),
{{178, 225, 227}, "Baby Blue", "228"),
{{54, 139, 160}, "Powder Blue", "229"),
{{79, 131, 171}, "Bright Blue", "230"),
{{56, 106, 145}, "Slate Blue", "231"),
{{7, 22, 80}, "Navy Blue", "232"),
{{249, 153, 162}, "Salmon Pink", "233"),
{{249, 103, 107}, "Coral", "234"),
{{227, 49, 31}, "Burnt Orange", "235"),
{{226, 161, 136}, "Cinnamon", "236"),
{{181, 148, 116}, "Umber", "237"),
{{228, 207, 153}, "Blond", "238"),
{{255, 203, 0}, "Sunflower", "239"),
{{225, 173, 212}, "Orchid Pink", "240"),
{{195, 0, 126}, "Peony Purple", "241"),
{{128, 0, 75}, "Burgundy", "242"),
{{84, 5, 113}, "Royal Purple", "243"),
{{177, 5, 37}, "Cardinal Red", "244"),
{{202, 224, 192}, "Opal Green", "245"),
{{137, 152, 86}, "Moss Green", "246"),
{{92, 148, 26}, "Meadow Green", "247"),
{{0, 49, 20}, "Dark Green", "248"),
{{93, 174, 148}, "Aquamarine", "249"),
{{76, 191, 143}, "Emerald Green", "250"),
{{0, 119, 114}, "Peacock Green", "251"),
{{89, 91, 97}, "Dark Gray", "252"),
{{255, 255, 242}, "Ivory White", "253"),
{{177, 88, 24}, "Hazel", "254"),
{{203, 138, 7}, "Toast", "255"),
{{152, 108, 128}, "Salmon", "256"),
{{152, 105, 45}, "Cocoa Brown", "257"),
{{77, 52, 25}, "Sienna", "258"),
{{76, 51, 11}, "Sepia", "259"),
{{51, 32, 10}, "Dark Sepia", "260"),
{{82, 58, 151}, "Violet Blue", "261"),
{{13, 33, 126}, "Blue Ink", "262"),
{{30, 119, 172}, "Sola Blue", "263"),
{{178, 221, 83}, "Green Dust", "264"),
{{243, 54, 137}, "Crimson", "265"),
{{222, 100, 158}, "Floral Pink", "266"),
{{152, 65, 97}, "Wine", "267"),
{{76, 86, 18}, "Olive Drab", "268"),
{{76, 136, 31}, "Meadow", "269"),
{{228, 222, 121}, "Mustard", "270"),
{{203, 138, 26}, "Yellow Ocher", "271"),
{{203, 162, 28}, "Old Gold", "272"),
{{255, 152, 5}, "Honey Dew", "273"),
{{252, 178, 87}, "Tangerine", "274"),

Hi, Are you planning to add support to wings ngs embroidery format? if it is not in the plan, I would be up to contribute on this with some guidance, thanks!

Each binding needs a test to see if the function call acts as we expect it to.

Currently we need a test.py to test each of the function wrappers available.

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.

been trying to use the dll in c#
using swig to generate classes
but when you put the swig wrap.c file in the libembroidery dll project it simply gives an error of statements

See the issue 106 from Embroiddermodder.

a few months ago I discovered an error reading the pes file.
in some certain files it is pecstart + 533 and in others it follows the pattern used for years which is pecstart + 532.
the biggest problem is figuring out why certain files are 533

segue file in pec start + 533

simbolo escola pequeno.zip

I was reading about this manual satin command in some comments here from 2014, at the time it looked like it should have been pushed upstream soon. I can not find it or was it renamed? And if it exists how to use it? Thanks for your help.

@marshallapparalautomation suggested to me via email that we could have a version of embroider that automatically converts the contents of a folder dynamically like a traditional UNIX daemon.

Rather than get knee deep in systemd, since this is something that could need versions for many different systems, lets sketch out a simple shell script.

Sketch of how the script would look, to be hooked onto, for example ~/.xinitrc.

# [At the bottom of .xinitrc]
export EMBROIDER_DIR="~/to_embroider"
. ~/embroidermodder2/embroiderd &

where embroiderd is our "UNIX daemon", here actually just a loop that runs without the need for a user-visible terminal

#!/bin/sh

while [ 1 ]
do
    for file in $EMBROIDER_DIR/*.svg
    do
        embroider -to dst $file
    done
    # To stop our script consuming too many system resources
    sleep 3
done

He can chime in here if that's not what what he means.

Copied from old to do list.

I've written other embroidery input and output libraries for Python and Java. And considered this rather strongly over the years, ran into various problems with libembroidery itself and corrected them after considerable thought.

Encoding

There is a need for a centralized set of methods to slightly abstract the embroidery between reading and writing (eg. https://github.com/EmbroidePy/pyembroidery/blob/master/pyembroidery/EmbEncoder.py). Without doing this you have the formats being hit with different commands and in different orders and some of these are not accepted by one format vs. another format.

Sometimes the expectation is that you perform a stop, trim, then a series of jumps, other times the format may expect you to trim, jump, then stop for the color change. You can load from a format that has needle-set commands rather than color-change commands, and you need to know that the first needle-set there isn't a color-change. It's setting the first needle, not performing the first change of the thread.

Nuances

• Some formats permit stops commands others only use color-changes.
• Sometimes you can fake a stop command such as with JEF.
• Some formats have explicit trim commands others, necessarily derive a trim command from 3+ jump commands.
• If the format has explicit trims, you can't imply a trim because maybe that's a really long stitch for puffy fabric.
• If a format had an implied trim, that needs to be made into a real trim. If your moving to a format with explicit trims.
• Some formats jump entirely to the place they are intending to stitch at then issue a stitch command moving to a different location. Others get within the range of the stitch point and then issue a stitch to the final location.
• The stitch command can mean <needle, move> whereas some others the stitch command means <move, needle>. So you stitch then apply the dx, dy. This means move to this location and stitch rather than "after stitching" go to this location.

There is a lot of nuance in formats. The only way I found to capture this nuances and consistently transfer formats from one to another is through a neutral intermediate format. This also allows you to add in some higher level commands without needing each writer to deal with them on a case by case basis.

eg. If you want to do a TIE_OFF_THREE_STITCH to tie off a stitch block you can easily have those added to your list of stitches without messing with anything in the writers. Because it will always go through the encoder which will turn that into the required sequence.

Writer Expectation

The writers for an embroidery format need to specify what type of commands and the ordering they expect. So if sequins are in the incoming data this can be stripped. Or if the data has speed commands (slow and fast seen in Barudan .Uxy) these can be removed from the data before sending the data to a format that cannot write speed commands. The writers would also dictate that that DSTs have a max jump length of 12.1mm. Where and another might have no max jump length.

Al of these nuances are a lot easier from a centralized location rather than trying to have every writer account for every nuance that may arise depending on the source of the data.

Threadlist

There's a need to correct the threadlist information. If you load a .DST embroidery file with 5 colors, but these give no color information (DST lack overt color information unless they have extended headers), this will be treated differently than thread entries that have actual discrete based on known information.

Metadata

There's also metadata between the formats. Sometimes label, author, copyright, etc. for particular formats can be written in a format (eg. PES v 4+), and another reader may provide that information.

Consistency of using Encoding

You'll notice that some items like #170 (consistent end command) gets fixed pretty easily with this, because you'd no longer be feeding your raw stitches from one format into another format. You can have all jumps and trims and whether there's a color-change or not, gets called an end to the stitchblock or colorblock respectively. Whatever the output format may be, we can go ahead and have those elements converted correctly for that writer. The writers can be guaranteed they will get consistent orderings and data types.

Matrix

Writing a Matrix is really powerful and let's you apply affine transformations to code. E.g (https://github.com/EmbroidePy/pyembroidery/blob/master/pyembroidery/EmbMatrix.py). These abilities are really important when it comes to things like composing patterns together (#174), where you need to know where the next pattern should be relative to the previous pattern, or to perform basic changes on an embroidery like slightly resize it.

Commands

There's a few more commands that occur within Embroidery than are accounted for within this library. These are seen in various embroidery formats, and should be included into libembroidery to be effective.

• SEQUIN_MODE: This usually causes the sequin hopper to engage on the machine.
• SEQUIN_EJECT: This is often a modified jump, but accounting must be made for when they are triggered differently.
• STOP: Stop as opposed to color-change exists in some formats. The distinction is that stop causes the machine to stop but not necessarily change colors.
• SLOW: U01 formats lets you mark commands as slow. This causes the machine to run at a lower RPM until it it hits a FAST command which restores it to the same speed.
• FAST: U01 move back into higher RPM mode.
• NeedleSet: Sets the needle rather than issues a ColorChange.

NeedleSet

Some formats specifically .U01 (.UXY) and some others use a needle_set command rather than a color_change. This differs from color-changes in 2 distinct and important ways. First, it occurs before sewing begins, rather than after sewing ends. And secondly it includes the needle number explicitly. This needs to accounted for and permit the conversion between color-change (which is usually just STOP) and a needle_set. This tends to require knowing how many needles the machine has or taking an educated guess.

STOP vs. COLOR_CHANGE

There are some formats that let you imply stop without a color-change. This is used when applying applique. We stop but we're not changing threads. Sometimes this even involves a FRAME_EJECT which is a trim and then moving to the top of the design to give the user unfettered access to the embroidery, to add the applique or whatever they are doing.

Versions

#139 is important. There needs to be given mechanisms for specifying versions of the file you're intending to write. For things like PES v 6 but also other methods of writing pes like pes without the pes block.

Or writing different versions of csv files. For example writing one that is actually correct to CSV specs vs. one that retains backwards compatibility. There are also very like to be dozens of potentially supported gcode formats #171.

Avoid Feature Creep.

A core library like this needs to just do the stuff it does in a well defined way. It doesn't need to do fill algorithms or anything outside of translations problems that can occur between different formats. If there is a need to have fills or higher level changes. That should be spun off into a different more powerful library that does that work.

You will notice that none of that is that extreme. There's a lot of little problems with the readers and writers and small bugs and edge conditions,

The biggest issues there are examples where the current descriptive language will not capture the nuance of all formats, and the need to generalize the format between reading and writing.

Additional features like composing two different files together get a lot easier, when this is done correctly. The bulk of the important work is understanding the formats themselves, which is mostly already done.

This is one part of the project that can be actually finished. A few isolated format fixes for a reader or writer would be the needed maintenance. Getting there requires that we get rid of the need for all writers need to check if they have an end command, or all writers need to deal with sequin stitches explicitly or this reader read this stuff verbatim but that's the wrong order for this writer.

Is there a way to distict multiple version from each embroidery format (if any)?
For instance:
Many Brother's machine support *.PES file,
but internally they only recognize a specific version of PES.
Let say Brother model X accepts PES ver 001, while Brother model Y accepts PES ver 006.

Okay, not every embroidery format has several version. But some of it has.

So, how we can instruct libembroidery to save to .PES in specific version?

hello, the dll is being generated without errors using swig and visual studio 2019 c.
but when I make her call through csharp she gives memory error in embpathern readprotected I've done many tests as admin and on another windows computer all with the same lock

Copied from old to do list.

I'm not able to open or save .gnc format files. Is it supposed to work?
I compiled everything.pro with Qt 5.7 on windows 7

Example SVG file which crashes the converter:

http://al.robotfuzz.com/~al/random/drawing.svg

Copied from old to do list.

I am new to machine embroidery, but have been looking for good libraries to help programatically generate patterns.
This library looks wonderful - so I cloned it and attempted to play with it locally.
I am a mac user and the cli tool compiles. However when running it there are a lot of issues that it's difficult for me to isolate and diagnose.

1. -to flag fails with Please enter an output format for your file, see --help. this is using the command embroider -t dst cmmn.jef

2. --test and --full-test-suite fails with [1] 61997 segmentation fault ./embroider --test

3. --render fails with:

   228 
   [1]    62063 segmentation fault  ./embroider -r cmmn.jef test.png
   

4. Basic conversion passes without seg faults - using the command emboider cmmn.jef cmmn.txt. However, converting to csv is showing indications of where segfault may be coming from as the "description" field for threads are showing some weirdness:

   "#","[THREAD_NUMBER]","[RED]","[GREEN]","[BLUE]","[DESCRIPTION]","[CATALOG_NUMBER]"
   "$","1","115","58","0","    -c, --circle     Add a circle defined by the arguments given to the current  to the current ���","rguments given to the current  to the current ���"
   "$","2","0","0","0","Black","Black"
   

   and for another file it gives:

    "#","[THREAD_NUMBER]","[RED]","[GREEN]","[BLUE]","[DESCRIPTION]","[CATALOG_NUMBER]"
    "$","1","101","100","32","under the terms of the zlib license.
    
        https://github.com/Embroidermodder/lib","github.com/Embroidermodder/lib"
    "$","2","45","100","105","fat.c bcf_difat_create(), Unexpected sector value %x at DIFAT[%d] ","%x at DIFAT[%d]"
    "$","3","0","0","0","END","END"
   

5. In good news embroider -F and embroider --help is working as expected.

My basic hardware settings are:

  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro16,1
  Processor Name:	8-Core Intel Core i9
  Processor Speed:	2.4 GHz
  Number of Processors:	1
  Total Number of Cores:	8
  L2 Cache (per Core):	256 KB
  L3 Cache:	16 MB
  Hyper-Threading Technology:	Enabled
  Memory:	32 GB

Running OSX 12.6

Let me know if there is any other information that would be helpful to provide?

I am interested in your project and would love to contribute anyway I can. Not a solid C developer.

Currently all stitches are black regardless, in theory this would be a few extra lines in the render_line function.

I was able to successfully convert a CSV file to a DST file, and make use of it on a Brother SE-400 machine. Hooray! However, I ran into a couple issues; this is one of them.

I constructed the CSV file based on examples found in the sample and test areas.

I thought that a JUMP would just be a longer version of STITCH, where perhaps the machine would prepare for a JUMP by making a couple of additional loops of the bobbin to anchor each end. However, the Brother seems to interpret the encoded JUMP as starting a new layer (new graphical layout preview box on the machine's screen) without cutting the thread; the user has to press the button to resume the pattern.

So, on the Brother anyway, JUMP is encoded to make a stitch to the given coordinates, start a new preview layer, and wait for the user to resume the pattern; the thread is not cut.

COLOR is encoded to start a new preview layer, and cut the thread, and wait for the user to resume after they have threaded the needle again. In the CSV, the coordinates are completely ignored.

I have not used a TRIM, so I'm not sure what its intended use is, compared to a COLOR change command.

Obviously, different machine models and different formats may handle these commands in varying ways. I'm not saying they behave wrong, so much as I was just capturing my understanding as an opportunity to clarify those differences in general documentation.

while(stitches)
    {
        dx = stitches->stitch.xx * 10.0 - xx;
        dy = stitches->stitch.yy * 10.0 - yy;
        xx = stitches->stitch.xx * 10.0;
        yy = stitches->stitch.yy * 10.0;
        flags = stitches->stitch.flags;
        jefEncode(b, (char)roundDouble(dx), (char)roundDouble(dy), flags);
...

This mechanism doesn't work. The error is introduced during the rounding of the dx, dy and that isn't tracked. The values of xx, yy, need to be the needle position given the summation of the actual dx, dy values given.

It needs to have the value of xx, yy the sum of the dx, dy values. And to round at the calculation of dx, dy.

I tried to import some simple SVG file from Inkscape. But it get only a empty scene.
I also tried DXF without success...

DSTs have a hacky sort of trim. They do series of jumps.
Jump: +2 +2
Jump: -4 -4
Jump: +2 +2

The net result is a jump of zero but this triggers a machine's trim.

Without libembroidery accepting that or allowing all jumps to be imply a trim (allow an option maybe) for DST it just makes stitches across the converted embroidery.

I am using the libembroidery-convert to convert ofm files to dst. Ofm files created using Design Shop Pro 9 can be converted without any trouble. Some ofm files (possibly a lower version) is not getting converted and I am getting segmentation issue.

Any help or hint to proceed will be helpfull.

Copied from old to do list.

See the contents of assets/designs/.

The idea is that by using LISP for user submitted functions we can have a much simpler data sanitation process.

Note that we're not supporting general LISP expressions (we may need to find out what this subset would be called) and they are loaded as YAML because they are only one input, one output functions as strings.

Copied from old to do list.

Hi folks,

An interesting crash was found while fuzz testing of the embroider binary which can be triggered via a malformed SVG file. Although this malformed file only crashes the program as-is, it could potentially be crafted further and create a security issue where these kinds of files would be able compromise the process's memory through taking advantage of affordances given by memory corruption. It's recommend to harden the code to prevent these kinds of bugs as it could greatly mitigate such this issue and even future bugs.

crash.svg

<polyline points -">

debug log

(gdb) r crash.svg
Starting program: libembroidery/build/embroider crash.svg
ERROR: emb-format.c embFormat_getExtension(), fileName argument is null
ELEMENT:
polyline
ATTRIBUTE:
points
VALUE:
-"
free(): double free detected in tcache 2

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7c84859 in __GI_abort () at abort.c:79
#2  0x00007ffff7cef3ee in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e19285 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7cf747c in malloc_printerr (str=str@entry=0x7ffff7e1b5d0 "free(): double free detected in tcache 2") at malloc.c:5347
#4  0x00007ffff7cf90ed in _int_free (av=0x7ffff7e4ab80 <main_arena>, p=0x5555555b5870, have_lock=0) at malloc.c:4201
#5  0x000055555557aca5 in readSvg (pattern=0x5555555b02a0, fileName=<optimized out>) at libembroidery/parsers.c:1876
#6  0x0000555555566e15 in convert (inf=0x7fffffffe6b9 "crash.svg", outf=0x0) at libembroidery/utility.c:3370
#7  0x000055555555e936 in main (argc=<optimized out>, argv=0x7fffffffe438) at libembroidery/embroider-main.c:247

(gdb) i r
rax            0x0                 0
rbx            0x7ffff7c5c740      140737350321984
rcx            0x7ffff7ca518b      140737350619531
rdx            0x0                 0
rsi            0x7fffffffde40      140737488346688
rdi            0x2                 2
rbp            0x7fffffffe190      0x7fffffffe190
rsp            0x7fffffffde40      0x7fffffffde40
r8             0x0                 0
r9             0x7fffffffde40      140737488346688
r10            0x8                 8
r11            0x246               582
r12            0x7fffffffe0b0      140737488347312
r13            0x10                16
r14            0x7ffff7ffb000      140737354117120
r15            0x1                 1
rip            0x7ffff7ca518b      0x7ffff7ca518b <__GI_raise+203>
eflags         0x246               [ PF ZF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

(gdb) exploitable
Description: Heap error
Short description: HeapError (10/22)
Hash: 974adaacfdf1bb2097994ce836781bcc.43f2159477851a2d62ba5c93fc7428d6
Exploitability Classification: EXPLOITABLE
Explanation: The target's backtrace indicates that libc has detected a heap error or that the target was executing a heap function when it stopped. This could be due to heap corruption, passing a bad pointer to a heap function such as free(), etc. Since heap errors might include buffer overflows, use-after-free situations, etc. they are generally considered exploitable.
Other tags: AbortSignal (20/22)

change

embFile_seek(file, pecstart + 532, SEEK_SET);
readPecStitches(pattern, file);

to

embFile_seek(file, pecstart + 528, SEEK_SET);
readPecStitchespes(pattern, file);

add void

static void readPecStitchespes(EmbPattern* patterns, EmbFile* file)
{
int stitchNumber = 0;
int val1 = 0;
int val3 = 0;
int val2 = 0;
int stitchType = 0;
while(!embFile_eof(file))
{

	    val1 =(unsigned char) binaryReadUInt8(file);
		val2 =(unsigned char) binaryReadUInt8(file);

		stitchType = NORMAL;
		if (val1 == 0xFF && val2 == 0x00) {
		   embPattern_addStitchRel(patterns, 0.0, 0.0, END, 1);
			break;
		}
		if (val1 == 0xFE && val2 == 0xB0) {
			 binaryReadUInt8(file);
			  embPattern_addStitchRel(patterns, 0.0, 0.0, STOP, 1);
			stitchNumber += 1;
		} else {
			if (val1 & 0x80) {
				if (val1 & 0x20) {
					stitchType =TRIM;
				}
				if (val1 & 0x10) {
					stitchType = JUMP;
				}
				val1 = ((val1 & 0x0F) << 8) + val2;
				if (val1 & 0x800) {
					val1 -= 0x1000;
				}
				val2 =  binaryReadUInt8(file);
			} else if (val1 >= 0x40) {
				val1 -= 0x80;
			}
			if (val2 & 0x80) {
				if (val2 & 0x20) {
					stitchType = TRIM;
				}
				if (val2 & 0x10) {
					stitchType = JUMP;
				}
				val2 = ((val2 & 0x0F) << 8) +  binaryReadUInt8(file);
				if (val2 & 0x800) {
					val2 -= 0x1000;
				}
			} else if (val2 > 0x3F) {
				val2 -= 0x80;
			}
		    embPattern_addStitchRel(patterns,  val1 / 10.0, val2 / 10.0, stitchType, 1);
		  stitchNumber += 1;
		}
	}

}

Copied from old to do list.

Saving a VP3 and reloading it can cause an internal registration error. I believe this is because the initial position of the color block is relative to 0,0 regardless of the position of the first stitch. So if the first stitch location is 0,20 it should call put the stitchblock information relative to a non-existent 0,0 initial stitch rather than center -> first stitch. Later positions actually can be relative to the first stitch. It then on loading needs to actually read the center position, and transpose the location of the stitch block back into the proper position.

Wilcom has a similar bug, and can't figure out the positioning, for what are manifestly correct files, turns them into gibberish. Especially if they aren't centered in the hoop.

There's also a large collection of other oversights that could cause flaws.

• design section is said to be hoop, but the files save literally no hoop data. Reading things by wrong names and skipping important things like multi-design read.
• hoop.threadLength = binaryReadInt32(file); /* yes, it seems this is not big endian */
  • Is neither threadLength nor little endian, it's the stitch count.
• calls "vp3WriteStringLen(file, "\0", 1);" to write 0,1,0 flag which denotes start of stitch block.
• writes Embrodermodder string in UTF-8 rather than UTF-16.
• vp3PatchByteCount(file, colorSectionLengthPos, -3);, because it doesn't properly note the 0 is part of stitches, and rather puts it on the front of all non-first stitch blocks.
• While vp3 can store 16 bit signed deltas at greater than 255 they stop being stitches and require cuts. So if you want the stitches to exist you need to limit their size.

See:
https://edutechwiki.unige.ch/en/Embroidery_format_VP3
https://github.com/tatarize/pyembroidery/blob/master/pyembroidery/Vp3Writer.py

Sirs,

I have managed to compile Embroidermodder2 on Ubuntu 14.04 64bit using Qt5 and successfully transferred a few of the sample files to PES format and embroidered them on my Brother Innov-is V7.

However every time I attempt to open any SVG file Embroidermodder2 crashes.

Is this because of 'work in progress' or do I have something wrong?

My main interest at this time is to convert jpg to svg via inkscape then embroider using Embroidermodder which isn't going to work if I can't import an svg file.

Help please.

regards

Copied from old to do list.

What functions are supported by the libembroidery-convert module and what is the general syntax that would need to be used to invoke several functions on an individual stitch?

For instance, is Stop, SqOn, TieOff, Drop Sequin, empty etc understood and translated in the conversion from CSV to DST? If they are, what would the syntax need to be for libembroidery to successfully convert it over to a DST file?

Also if I'm going from a THR file to CSV (I go here to insert JUMP functions to invoke trims, since it isn't supported in Thred natively due to when it was written) and I wanted to specify certain colors, say color 2, what would that syntax be? I know where the color changes happen because it shows up as UNKNOWN in the CSV file. In Wilcom, it's Color (2), what would the syntax be that libembroidery would understand and carry over? This I would need for PES, PCS, JEF files etc.

Thanks for this little conversion tool. I didn't realize that it could be compiled and run separately and I'm really enjoying the fact of being able to invoke trims in files created by Thred, I hate those long jump stitches it would generate and sometimes can't distance points greater then .5" to force a trim that way. If we can use other functions that would be great.

Thanks

We write accurate color counts, then pad up to 16.

    colorCount = (unsigned char)embThreadList_count(pattern->threadList);
 ...
    for(; i < 16; i++)
    {
        binaryWriteUInt(file, 0); /* write remaining colors to reach 16 */
    }

We read the written color count, then try to read stitches that could be zero.

The end result is that it produces what seems like correct files, but then cannot read them. I'm unsure whether the color count should always equal 16 with the padding or if the padding should be omitted. But, it's an issue either way. It cropped up in MobileViewer's transcoded version.

colorCount = binaryReadUInt16(file);

    for(i = 0; i < colorCount; i++)
    {
        ...
        embPattern_addThread(pattern, t);
        ..
    }
    ...
    st = binaryReadUInt16(file);
   ...

String match to:

"#Created in Embird or "#","Embroidermodder 2 CSV Embroidery File"

Because Embroidermodder wrongly doesn't accept 80 04 as a jump but calls it a trim, sequences which are jumps are not processed as jumps. Jump sequence seems to properly be 80 04 xx yy means this is a jump stitch. When it loads the format it calls those 80 04 trims and manages to draw the first jump stitch in the format.

See this error properly demonstrated here:
http://www.wasbo.net/svg2embr/phpBB3/viewtopic.php?f=8&t=11

fresh build of libembroiderery on mac 12.1 but conversion from PES to SEW produces invalid results

Copied from old to do list.

So currently if you run

./tests.sh

on a Linux system then the last line of output is:

2.650273%

which is the proportion of conversions from one format to another that appear successful. This is probably never going to be 100%, but it should be much higher for v 1.0.

Also the percentage is based on what tests we do, so it may go down as the testing becomes more thorough.

I'd tried to place EmbLayer reasoning in both ends, so it really needs to be sorted out in libembroidery on the grounds that SVG need layers and so full layer management is necessary: at least for the shapes part of the pattern.

Also, TextProperties and font management should be part of libembroidery for the purpose of generating text patches which is a major use of embroidery machines.

G'day(and Happy New Year). I've been working with this program for a while trying to make a little pattern and noticed that for some formats my pattern is ... a bit mangled. I've uploaded a sample file and some scripts to try this stuff out in my fork(https://github.com/leesdolphin/Embroidermodder/blob/master/convert-roundabout.py#L109)

Basically converting a really simple 1cm box from CSV to HUS to CSV triples the height, doubles the width and all around messes with the way it should be.

Some formats are more susceptible than others, for example TAP handles the conversion fine; however PES decides that once it's done with a box-ish it'll drift off toward (40, 400).

The script expects to be placed in the root of the repo; and will do a build(qmake followed by make for libembroidery and libembroidery-convert) before running libembroidery-convert on the input file for each supported format. It'll then create a TXT file from the converted format and compare it to the original's TXT file by running diff in side-by-side mode.

For Example:

CSV -> CSV(adds a flag stitch for every conversion):

9                                                               |  10
                                                                >  0,0 color:0 flags:1
0,0 color:0 flags:1                                                0,0 color:0 flags:1
<snip>

CSV -> HUS(produces weird stitches with no apparent relation to the inputs)

9                                                               |  11
0,0 color:0 flags:1                                                0,0 color:0 flags:1
0,0 color:0 flags:1                                             |  -10.4,8.8 color:0 flags:0
0,0 color:0 flags:1                                             |  -21.4,-2.3 color:0 flags:0
0,0 color:0 flags:0                                             |  -25.6,-6.5 color:0 flags:0
0,10 color:0 flags:0                                            |  -28.2,-9.1 color:0 flags:0
10,10 color:0 flags:0                                           |  -35.8,-16.7 color:0 flags:0
10,0 color:0 flags:0                                            |  -23.1,-4 color:0 flags:0
0,0 color:0 flags:0                                             |  -23.1,-4 color:0 flags:0
0,0 color:0 flags:16                                            |  -23.1,-4 color:0 flags:0
                                                                >  -33.5,4.8 color:0 flags:0
                                                                >  -33.5,4.8 color:0 flags:16

Copied from old to do list.

Hi, I am working on an embroidery order management project. I'm hoping that once your development is complete in python then i will be able to use your software within mine. I'm not sure if you have heard of EMBtrak. They are a US based software company that have a bit of software that allows the user to input orders and combine it with the embroidery file and colour information with in the main module. Then produce production worksheets with all the required information. This product can be liscenced for a crazy amount of money. But i'm hoping to produce something similar and take it to the next level.
In the UK Wilcom is probably the most used Digitising software. The standard file type is EMB, this will save multiple colorways for the same design in 1 file. It would be a great help if you would consider adding this to the supported file types for embroidermodder2.

Thanks for your efforts and can't wait to see EM2!!

now it is possible to generate the dll using swing
but to an error in it using the convert method generate the following error in the image