The ultimate goal is to export the pages in a fireworks png file to individual images. So I have a couple questions:
Some digging I did on my own for the private chunk types in Adobe Fireworks files is as follows (assume Python slicing notation):
prVW ("thumbnail preview?")
Data format:
- bytes[0:4] - Chunk length
- bytes[4:8] - Chunk type
- bytes[8:10] - zlib file magic 0x789c
- bytes[10:-8] - zlib data
- bytes[-8:-4] - zlib checksum
- bytes[-4:] - Chunk checksum
After decompressing, the first 4-bytes are the value "0xcafebeef",
likely another file magic byte value for whatever format the data is
in.
mkBF
Data format:
- bytes[0:4] - Chunk length
- bytes[4:8] - Chunk type
- bytes[8:12] - 0xfadecafe (file magic?)
- bytes[12:16] - big-endian length value?
- bytes[16:80] - 64-byte NULL-padded data field
- bytes[80:84] - Chunk checksum
mkBS
Data format:
- bytes[0:4] - Chunk length
- bytes[4:8] - Chunk type
- bytes[8:10] - zlib file magic 0x789c
- bytes[10:-8] - zlib data
- bytes[-8:-4] - zlib checksum
- bytes[-4:] - Chunk checksum
mkBT
Data format:
- bytes[0:4] - Chunk length
- bytes[4:8] - Chunk type
- bytes[8:12] - 0xfacecafe (file magic?)
- bytes[12:16] - Unknown big-endian value. Increments for
each mkBT chunk present, and appears to only
consume the lower 24-bits.
- bytes[16:84] - 68-byte NULL-padded data field
- bytes[84:86] - zlib file magic 0x789c
- bytes[86:-8] - zlib data
- bytes[-8:-4] - zlib checksum
- bytes[-4:] - Chunk checksum
This chunk may contain a split/spanned zlib stream, as the decompressed
data is cut at 64kb per mkBT chunk and does not appear to carry a zlib
checksum value. Decompressing each zlib stream and then concatenating them
all together does not appear to be wrong.
mkTS
Data format:
- bytes[0:4] - Chunk length
- bytes[4:8] - Chunk type
- bytes[8:10] - zlib file magic 0x789c
- bytes[10:-8] - zlib data
- bytes[-8:-4] - zlib checksum
- bytes[-4:] - Chunk checksum