File Extension .art - request inkstitch/inkstitch#1329

[tatarize]

@Stef12341234 @lexelby @kaalleen
.art formats are very much similar to other formats made with the same source code as Wilcom and OESD .ArtSizer. These are Compound File Binary Format files with several regular sub files without them:

• [5]SummaryInformation
• [5]WilcomDesignInformationDDD
• AUX_INFO
• Contents
• DESIGN_ICON

The Contents is the important file and this is 4 bytes of uncompressed length followed by the zlib data, this content is swizzled with (XOR D2, cycle-shift left 1). Applying these two will let you uncompress the data within Contents.

eg.

import compoundfiles
import zlib


def swizzle(b):
    b ^= 0xD2
    b <<= 1
    b |= b >> 8
    return b & 0xFF


def parse_art_file(file):
    with open(file, 'rb') as f:
        contents = compoundfiles.CompoundFileReader(f).open('Contents')
        contents.seek(4)  # file size
        return zlib.decompress(bytes([swizzle(b) for b in contents.read()]))

Looking at the actual data format it appears to be a triplet-coded relative movement format. Which is would make reading the file format quite possible. Though writing formats is considerably harder since it requires knowing what every single part does rather than just most parts. Also, .art files just like .emb files and the Janome version that also sublicenses the same stuff are all similar though with different swizzles. I've had the initial formatting bit for the better part of year.

https://github.com/EmbroidePy/pyembroidery/blob/master/pyembroidery/ArtReader.py

While it is true that no company has released detailed information on how their formats work (though I did get some of this .ZSK formatting from the manufacturer but it was after a client purchased a $100k with them). The reverse engineering process does not depend on that information. It depends on a very specialized skill set and doing the actual work, I just haven't bothered to finish up the .art reader and I certainly haven't done a sufficient study to produce these types of files. So it is somewhat disingenuous to say that this documentation is needed and certainly not accurate that the lack of this documentation is the reason it is not being implemented there, it's just not a skillset possessed in the project currently and you'd be better off bugging me about it. But, I'm not thrilled on the CFB format requiring a external library to be read, and so often programs accept DST files that it's usually not worth the effort writing such a file format though reading them is usually quite useful.