tatarize
commented
3 years ago This is likely due to a bug in EmbroidePy/EmbroideryIO#16 if you used https://htmtopdf.herokuapp.com/embroidery/ and it works then it's likely a bug fixed in the python library pyembroidery but still extant in the EmbroideryIO code. Since the given online converter is based on the python version of my same code base. But the java version was for EmbroiderModder android/java app: https://github.com/Embroidermodder/MobileViewer this broken formatting needs to be checked.
This may be related to #92. Jef as a format does not automatically establish any viewing data since it doesn't have any bitmaps or anything else contained in the file and these are generated directly from the file data.
This might be related to some of the efforts done in this thread. https://github.com/CreativeInquiry/PEmbroider/issues/83
So far my workflow always required me to open the generated .jef file in Premier+2 app or use https://htmtopdf.herokuapp.com/embroidery/. I use these apps to simple hit the export option before using it on my machine (Janome 230e)
Today I did a simple test; drawing 5 shapes each with a different fill. When using the .jef coming straight from PEmbroider my machine seems to still have a memory of one of my older stitchings; a fox. But when selecting the same file exported through Premier+2 all is fine. Here some photo's as proof and the two .jef files.
On the left you see the final stitching, which looks good and the machine preview image, using the premier+2 exported file.
On the right without the premier+2 export, the preview image shows some unrelated older image. It does have the info for the different color layers but also includes a final 5th layer from this unrelated older file. You can also see that in the stitch photo it started stitching that 5th layer, before I interrupted the process.
Archive.zip
I know that Premier+2 does some extra culling, so I was hoping to not have to use it for future projects.