Initial work on a Karbon CDR import filter

[Friedrich W. H. Kossebau]

Hi Sven,

Am Sonntag, 29. Januar 2012, 02:00:59 schrieb Sven Langkamp:
> On Sat, Jan 28, 2012 at 3:24 AM, Friedrich W. H. Kossebau
> 
> <kossebau at kde.org>wrote:
> > Hi,
> > 
> > last weekend I started to try if I can do an import filter for the
> > CorelDraw
> > file format. I managed to get first parts of that format decoded and
> > turned into some Karbon document data, see also my blog entry
> > 
> > http://frinring.wordpress.com/2012/01/28/trying-to-read-files-from-the-
> > past/
> > 
> > Some questions:
> > Initially I tried to create directly a KarbonDocument object, not
> > another
> > SVG
> > file. But then I found out that shapes like e.g. Rectangle and Ellipsis
> > are only provided by factories from plugins, so I cannot create them
> > directly from
> > code, is that correct? Do I really have to instead create a SVG file as
> > output?
> > 
> > Anybody would like to join the efforts? You are welcome! The CDR formats
> > I will work on are the ones for version 4 and 5 (as these are the ones
> > of the files I am interested in). So people with other versions will
> > have to scratch
> > their itch themselves :)
> > 
> > You can find the current state in the branch “CDRImport” in my clone of
> > the Calligra repo here:
> > 
> > http://quickgit.kde.org/?p=clones%2Fcalligra%2Fkossebau%2Fcalligra.git&a
> > =summary
> Why are you using libcdr? No idea in what state it is, but that would share
> the code with other projects and produce less duplicated code.

"_not_ using" you meant, and the question/suggestion is valid, I have posed 
this one to myself as well.

The negative answers to this question why I stick to my own code for now:
* can use the APIs I know
* can customize the code to Calligra/Karbon
* can use my own coding style
* do not need to spend time with coordination
* do not need to make comprimises
* am interested in the v4 format, while libcdr is >=v7 with lots of if/else

which means maximal fun for me, and besides being able to read my files, fun 
and experience is my motivation.

Then, the most time is spent on understanding the format, writing the reading 
and conversion code is rather straightforward, so code duplication is less an 
issue. And given the opensource nature of our projects, we can (and at least I 
do) peek into each other's sources to compare the format interpretation 
knowledge. Though I have to admit that I have a little problem to extract the 
format spec directly from code, for the usual problems with reading someone 
else's code :) 
As maintaining a separate document with just the spec info is work duplication 
as well I started to experiment with a single-source concept, having the spec 
in some XML-based format, from which C-code struct declarations are generated 
as can be a HTML/ODF-document, see
https://projects.kde.org/projects/calligra/repository/revisions/filters-
karbon-cdr/changes/filters/karbon/cdr/cdr4structs.format
But this only works as I read the data in chunks and then map the compiler-
generated data-layouts to the chunk, while libcdr and Uniconvertor read the 
data field-by-field. Then I might learn to tell my compiler not to add padding 
to the formats, to align e.g. int32 (as it happens to me on 64-bit :/ ).

Next thing I would like to do is to generate an osd (Okteta structure 
definition) from that file, so I can more easily navigate through the raw file 
in Okteta :)

I am seeing to get this format description spec format non-CDR specific as 
well as non-Qt specific, as I see chances for this to be useful for 
descriptions of other binary formats as well.

As I meanwhile have learned from Björn that for the Excel import filter there 
is a similar approach to generate C code for the enums and structures from the 
file records.xml, but I still need to look at that.

Cheers
Friedrich