PES section

The sections within PES are properly modular. They either occur or they do not occur. They occur in the same order, and changing this order will cause a crash.

Within the PES section of the PES format we have only four elements. The header, a control code, blocks, and later version have a group-order section element.

The header differs based on the version. The header, like blocks, is followed by the control code. If there are no blocks then the header is followed by the control code 0x0000 0x0000. If instead there are blocks following the header, this is indicated with 0xFFFF 0x0000. The final block is terminated with 0x0000 0x0000.

Control codes

If a format does not know how large it is or whether particular elements exist or not it cannot know whether there's more data. And since there's a PEC section appended to the end of these files, it's impossible to know where they end without some form of control code (or paying attention to what the absolute PEC byte offset value is and deciding the PES section is the rest of the data before that). The version 1 was heavily reliant on control codes. Later version much less so.

Type	Bytes	Value	Description
u16	2	0xFFFF | 0x0000	Control code where 0xFFFF means additional blocks follow, and 0x0000 means no more block follows
u16	2	0x0000	Unknown

Each section is terminated with a control sequence of either 0xFFFF 0x0000 which means additional blocks follow, or 0x0000 0x0000 which means no more block follows. If, for example, the header is the only element it will end with the control code 0x0000 0x0000.

It is an error to declare in the header that there are zero stitch blocks but have a control code that says additional blocks follow. If the header declares there is 1 section within the CEmbOne/CSewSeg block but the control code is 0x0000 0x0000, even if the expected data is there, this is also an error.

Blocks

Type	Bytes	Value	Description
u16	2	S	Length of following string
char	S		Section identification
section			Data depends on the block type

All sections contain 2 bytes of data before their names to declaring the length of the name. So CEmbRect is 8 characters so it has a u16 length of 8, before the letters "CEmbRect" but CSewSeg has 7 characters so has a u16 length of 7. So if we have a CEmbRect section we will have a 0xFFFF 0x0000 to say continue reading from the previous block or the header, 08 00 (little endian value 8) to say we have 8 characters in the name, then "CEmbRect" to declare the section.

Section sizes are often variable in length, owing to the number of points in various sections etc. So exact byte offsets cannot be given, but they can be broken into sets of discrete objects within themselves.

Section	Description
Header	Format id, version, name, colors, etc.
CEmbOne	Coordinate transformation matrix, etc.
CSewSeg	Stitch sewing coordinates, etc.
CEmbCirc	Oval objects.
CEmbRect	Rounded rectangle
CEmbLine	Unknown
CEmbPunch	Unknown
CSewFigSeg	Unknown
CLetter	Unknown
CEmbNText	Unknown

Group-Order

Version 6 is known to have the following sections.

Type	Bytes	Value	Description
u32	4	0x00000000	4 bytes of zeros. (unknown)
u32	4	0x00000000	4 bytes of zeros. (unknown)
order	n * 8		order data

Note: N is equal to the declared number of objects + 1 in the header. It's equal to the number of color transitions, it is unknown what the first set of zeros mean. It could be similar to the csewseg_color section which has an entry for each transition and thus always says the 0th color is used first on the 0th colorblock.

order subsection

The order is omitted in version 1. But is known to exist in version 6 and likely since version 4. It governs the ordering of the sections. If a file is reordered in PE-Design it isn't changed in any of the structure but the order is changed in the order here.

Type	Bytes	Value	Description
u32	4	0, 1, 2, 3	Section number.
u32	4	0, 1, 2, 3...	Group Index, 0.

This element governs the grouping and ordering of the various objects in the file. How it actually does that is still unknown.