VP3 registration error

[tatarize]

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

[tatarize]

It might also be rounding error of the recorded centerx, centery value not being exactly centerx, centery but all calculations must be relative to that position so it must be maintained properly rather than writing it down and not fixing the values relative to that rounding error (which would only crop up in the layers themselves). This would mean all layers would be sort of wrong relative to the rounding error on the centerx, centery position.