CDR file format reverse engineering
CDR uses RIFF container.
LIST chunks can be compressed, in this case LZW algorithm is used, and the chunk starts with FourCC ‘cmpr’.
cdr_explorer (a part of sK1 project sK1) is a program for file format research.
Chunk descriptions
<vrsn>
| Offset | Length | Value |
|---|---|---|
| 0 | word | version*100 |
<DISP>
Thumbnail/Preview image in BMP format with partially skipped header.
<bmpt>
Collection of <bmp > chunks
<bmp >
Bitmap image in BMP with modified header.
| Offset | Length | Value |
|---|---|---|
| 0×36 | word | Color model * |
| 0×42 | dword | Size of bitmap file |
| 0×50 | dword | Start of bitmap data |
| 0x7a | – | Start of pallete data |
[*] Color Models: (’Invalid’, ‘RGB’, ‘CMY’, ‘CMYK255’, ‘HSB’, ‘Gray’, ‘Mono’, ‘HLS’, ‘PAL8’, ‘???’, ‘RGB’, ‘LAB’)
<filt>
Collection of <filc> chunks
<filc>
Contains <fild> chunk. (Never seen any more chunks here, so what is the reason for this chunk existence?)
<fild>
Fill info.
| Offset | Length | Value |
|---|---|---|
| 0×0 | dword | Fill ID |
| 0×4 | dword | Fill Type * |
| 0×8 | word | Color Model |
| 0xA | word | ??? |
| 0xC | dword | ??? |
| 0×10 | dword | Color Bytes |
For Transparency the 1st 8 bytes are used. Gradients are not rev.eng.ed yet.
[*] 0 - Transparency, 1 - Solid, 2 - Gradient
Color Models are (’Invalid’, ‘Pantone’, ‘CMYK’, ‘CMYK255’, ‘CMY’, ‘RGB’, ‘HSB’, ‘HLS’, ‘BW’, ‘Gray’, ‘YIQ255’, ‘LAB’)
Color bytes: bbggrrXX for RGB, ccmmyykk for CMYK
<otlt>
Collection of <outl> chunks.
<outl>
Info about outline.
| Offset | Length | Value |
|---|---|---|
| 0×0 | dword | Outline ID |
| 0×4 | word | Line Type |
| 0×6 | word | Caps Type |
| 0×8 | word | Corner Type |
| 0xA | word | ??? |
| 0xC | word | Line Width |
| 0xE | word | ??? |
| 0x1C | 6 x 8 bytes | XForm Matrix ??? |
| 0x4C | word | Color Model |
| 0x4E | word | ??? |
| 0×50 | dword | ??? |
| 0×54 | dword | Color Bytes |
| 0×68 | – | Dash Bytes * |
[*] list of words starts from the num of ‘dashes’. Most likely ‘length of dash’/’length of space’
<loda>
For a moment I seen 7 different types of <loda> chunks (there are some not-quite-interesting 0×10,0×11,0×12 types also).
| Type | Object |
|---|---|
| 0 | ‘Layer’ |
| 1 | ‘Rectangle’ |
| 2 | ‘Ellipse’ |
| 3 | ‘Line/Curve’ |
| 4 | ‘Text’ |
| 5 | ‘Bitmap’ |
| 20 | ‘Polygone’ |
Common header for all types
| Offset | Length | Value |
|---|---|---|
| 0×0 | dword | Chunk Len |
| 0×4 | dword | Num of args |
| 0×8 | dword | Start of args |
| 0xC | dword | Start of arg types (reverse order) |
| 0×10 | dword | Type of chunk |
Types of args
| Type | Value |
|---|---|
| 0xa | outl_ID |
| 0×14 | fild_ID |
| 0x1e | Coords * |
| 0×64 | ? |
| 0xc8 | stlt_ID |
| 0x38e | Text |
| 0x3f2 | ? bitmap rel. |
| 0x7d0 | Pallete |
| 0x1f40 | Lens ? |
| 0x1f45 | Container ? |
| 0x2af8 | Polygone |
| 0x2ee0 | ??? |
| 0x2efe | Rotation angle * |
| 0x3e8f | ? txt rel. |
| 0x36b1 | ? txt rel. |
| 0x4ae2 | ??? |
[*] have to be divided by 1000000 to convert to ‘degrees’
Coords
Have to be divided by 10000 to calculate value in millimeters.
Type 1 ("Rectangle") and Type 4 ("Text")
Contains a pair of coords for the 2nd corner (the 1st corner is always 0:0). For Rectangle there are also 4 dwords with radius of corners rounding.
Type 2 ("Ellipse")
Contains a pair of coords, 2 dwords with start/end angles (for recalculate to degrees have to be divided by 1000000)
Type 3 ("Line/Curve")
The offset points to the dword with a number of nodes, followed with this num of coords pairs, and right after coords the properties of nodes are stored (one byte per node).
Type 5 ("Bitmap")
Related to inserted bitmap. The table below didn’t checked atm. After them there is a structure:
| Offset | Length | Value |
|---|---|---|
| – | 4x2xdwords | Coords? |
| – | word | bmp_clr_mode |
| – | word | color depth |
| – | dword | width (px) |
| – | dword | height (px) |
| – | dword | idx1 ??? |
| – | dword | number of <bmp > |
| – | dword | idx2 ??? |
| – | dword | idx3 ??? |
| – | dword | idx4 ??? # |
| – | dword | idx5 ??? # |
| – | dword | idx6 ??? # |
| – | – | Coords List * |
[#] ver7 - no idx4, idx5 and idx6; ver8 - no idx5 and idx6 [*] see description in Type 3, seen only files with 5 nodes (rectangle?)
Type 20 ("Polygone")
There are dword for diameter and 3 pairs of coords. The 2nd pair seems to be coords of polygone center.
"Polygone" arg 0x2af8
| Offset | Length | Value |
|---|---|---|
| 4 | dword | Num of angles |
| – | 8*dword | ??? |
<ftil>
| Offset | Length | Value |
|---|---|---|
| 0×0 | 6 * 8 bytes | ??? |
<trfl>
Collection of <trfd> chunks.
<trfd>
| Offset | Length | Value |
|---|---|---|
| 0×0 | dword | Chunk Len |
| 0×20 | 6 * 8 bytes | XForm Matrix |
<arrw>
| Offset | Lenght | Value |
|---|---|---|
| 0×0 | 0×4 | arrw_Id |
| 0×4 | 0×4 | ??? |
| 0×8 | 0×2 | Num of coords |
| 0xA | 0×4 | Offset to coord * |
| 0xE | NumOfcoords | Types of points |
| – | NumOfCoords*2*4 | Coords |
[*] counted from 0×8
Разное
<ptrt> все четыре dword совпадают с первыми 4 dword в <sumi>
Для первого из “пары странных dword” перед координатами в <loda> нашлось совпадение в stlt.
В <loda> для powerclip используется свойство 0x1f45. По соответствующему смещению лежит структура начинающаяся с индекса.
Объекты попавшие в контейнер лежат в <doc >.<clpt>.<grp > В этой <grp > есть <spnd>, содержимое которой совпадает с индексом из <loda> powerclip
<flgs> – четыре байта.
| Byte: | 3rd | 2nd | 1st | 0th | Comment |
|---|---|---|---|---|---|
| Layer | 0×98 | ||||
| 0x0a | Guides | ||||
| 0×08 | Desktop | ||||
| 0×00 | Layer1 | ||||
| 00/01 * | 0x1a | Grid | |||
| Page | 0×90 | ||||
| 0×00 | Regular page | ||||
| 0×40 | With lens or container | ||||
| Obj. | 0×08/0×09 | ||||
| 0×02 | Regular | ||||
| 0x0a | Xparent outline? | ||||
| 0×08 | Has Lens? | ||||
| 0×10 | Container? | ||||
| Grp | 0×10/0×11 | ||||
| 0×00 | 0×00 | Regular | |||
| 0×80 | 0×08 | In <clpt> | |||
[*] Видел два варианта. 0×01 имеется в CDR12.cdr. Интересно чем отличается от других Grid. На визитке нулевой байт в Grid имеет значение 0x5a (90). Что это?
Описание градиентов
смещения для ver12, у ver13 всё сдвинуто дальше.
| Offset | Length | Value |
|---|---|---|
| 0×0 | dword | Fill Id |
| 0×04 | dword | Fill Type |
| 0×08 | dword | Gradient Type * |
| 0x0c | dword? | ??? |
| 0×10 | dword? | ??? |
| 0×14 | dword | какой-то угол??? бывает 0 и 45 градусов |
| 0×18 | dword | ??? 0x3c |
| 0x1c | dword | ??? 0, 17 and 19 |
| 0×20 | dword | “angle” (какашка там где было 0x1c == 19) |
| 0×24 | dword? | ??? в одном из встроенных градиентов этот и следующий dword – маленькие отрицательные значения |
| 0×28 | dword? | ??? |
| 0x2c | dword? | ??? |
| 0×30 | word? | ??? видел только 1 (возможно это выбор цвет/шаблон и т.п.) |
| 0×32 | word | “midpoint” |
| 0×34 | word | num of palletes |
| 0×36 | word (ver13 – dword + byte) | ??? для ver13 надо уточняться |
| 0×38 | palletes | указанное число палитр |
[*] Linear/Radial/Conical/Squared
после каждой палитры идут 4 байта, смахивающие на % от длины
в ver13 “палитры” как-то более по-дурацки описаны
<txsm>
Если первый dword == 0, то всё сдвигается на 0×20 байт, при этом по смещению 0×82 лежит dword с числом блоков состоящих из 5-байтного индекса(?), описания кодировки, описателей символов и собственно текстовой строки
текстовая строка заканчивается \x00, за ней начинается следующий блок.
В signaturen обнаружены кучи пустых блоков с количеством символов 0, вместо описателей и текстовой строки в них лежит один нулевой байт (надо учитывать в смещении)
Для версий с 8 по 13 после первого word идут два байта флагов.
Первый байт флагов для txsm
с0 – восемь байт (индексы?)
30 – восемь байт (два по четыре без деления?)
31 – четыре байта описания шрифта, потом восемь байт как в 30
03 – четыре байта описания шрифта, потом ещё 4 байта без деления
02 – четыре байта без деления?
01 – четыре байта описания шрифта
Второй байт флагов (отсутствует в версии 7)
08 – есть название кодировки
00 – нет названия
в версии 13 перед названием есть dword, предположительно с длиной названия название задано в ucsc-16
ver13
15 00 00 08 03 00 00 00 45 00 4e 00 55 00
04 00 01 08 02 00 cc 00 03 00 00 00 52 00 55 00 53 00
01 00 [31] [08] {02 00 cc 00} {05 00 00 00 20 00 00 00} [03 00 00 00] {52 00 55 00 53 00}
01 00 30 00 fb ff ff ff 1b 00 00 00
01 00 30 00 02 00 00 00 1b 00 00 00
01 00 31 08 02 00 cc 00 fe ff ff ff 19 00 00 00 03 00 00 00 52 00 55 00 53 00
ver12
01 00 00 08 55 53 00 00
04 00 01 08 02 00 cc 00 52 55 00 00
14 00 00 08 55 53 00 00
01 00 30 08 fb ff ff ff 1b 00 00 00 55 53 00 00
01 00 30 08 02 00 00 00 1b 00 00 00 55 53 00 00
01 00 31 08 02 00 cc 00 fe ff ff ff 19 00 00 00 52 55 00 00
01 00 31 08 02 00 cc 00 05 00 00 00 20 00 00 00 52 55 00 00
В multiline вместо кириллицы 0x3f во всех версиях от 11 до 7
ver10,11 – четырёхбайтные описатели, нету “юникодного” флага, весь текст однобайтный
нету dword с числом байт в строке перед текстом
01 00 00 08 55 53 00 00
06 00 01 08 02 00 cc 00 52 55 00 00
16 00 00 08 55 53 00 00
ver8,9
четырёхбайтные кодировки
01 00 00 00
04 00 01 00 02 00 cc 00
14 00 00 00
01 00 30 00 fb ff ff ff 1b 00 00 00
01 00 30 00 02 00 00 00 1b 00 00 00
01 00 31 00 02 00 cc 00 fe ff ff ff 19 00 00 00
01 00 31 00 02 00 cc 00 05 00 00 00 20 00 00 00
01 00 00 00
06 00 01 00 02 00 cc 00
16 00 00 00
01 00 00 00
05 00 00 00
06 00 00 00
0a 00 c0 00 c8 6d 5d 07 a8 15 6e 07
0b 00 c0 00 c8 6d 5d 07 a8 15 6e 07
ver 7
трёхбайтные кодировки
01 00 00
04 00 01 02 00 cc 00
14 00 00
01 00 30 fb ff ff ff 1b 00 00 00
01 00 30 02 00 00 00 1b 00 00 00
01 00 31 02 00 cc 00 fe ff ff ff 19 00 00 00
01 00 31 02 00 cc 00 05 00 00 00 20 00 00 00
Тестовые файлы
<outl>
В <outl> есть два неопознаных word-а рядом с Corner Type и Line Width.
- разные типы соединения (Join) – Miter/Round/Bevel
- стрелки какие-нибудь на концах
- если есть ещё чего – “всё неси ему в горстях”
Штрих-пунктир
Пара линий длиной во весь лист, большой и очень большой 
толщины, выполненных каким-нибудь весёленьким штрих-пунктиром (чтоб штрихи были поразномастнее). Хорошо бы померять какая получается длина штрихов (хотя бы самых длинных у каждой линии).
<fild>
Для <fild> хочется файлы с хорошо описанными градиентами (можно несколько градиентов применённых к прямоугольникам разного размера – 3-5 сверху вниз с увеличивающейся длиной). Плюс файлы с заливкой битмапом (наверное есть несколько вариантов типа масштабирования по размерам объекта и мозаики?)
<bmpt>
Файл со вставленными несколькими разными маленькими битмапами (описание координат, чтобы их можно было отличить от всякого разного в битмапах).
Файл с разными непрямоугольными битмапами.
<loda>
Rectangle
Один прямоугольник с разными радиусами закругления углов, чтобы определиться какой из углов какой.Если это вообще возможно сделать в Corel
Text
Нужно пару файлов с описаным расположением текста (координаты).
Хочется artistic text, поскольку наверняка окажется как с прямоугольником: простой текст – это артистик со всеми параметрами 0 или 1.
Другие типы объектов
Неплохо бы поиметь другие типы объектов (star, spiral, complex stars, tables и др. чего найдётся), хотя бы по одному образцу в 12-ой (например) версии.
И пару файлов с _другими_ линзами, чтобы проверить как это повлияет на тип аргумента.
