EMF parser / renderer in playground

G'day team,

First of all, my congratulations on the way KOffice 2 is coming together.
Would like to have been more involved, but I've got a few too many projects
already :-(

One of those projects might be of interest to KOffice though - an Enhanced
Metafile parser / renderer. I know of the koffice/filters/libkowmf code, but
I'd like to have a common solution amongst KOffice, Okular and maybe KDEPIM,
plus perhaps external users, and there were a few things I really didn't like
about the libkowmf architecture.

So I started from scratch, and am slowly adding record types as required to
get test examples to parse / render.

My design uses a parser that calls out to a selected output Strategy (right
now there are two - one that just prints debug messages, and one that renders
using a QPainter).

The code can be seen at
http://websvn.kde.org/trunk/playground/graphics/okular/emf/

I'm not very happy with lots of things in it (everything from my mismatched
tabs/spaces to text placement to record types that just don't work) but any
help / suggestions would be appreciated.

Brad

_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

[Cyrille Berger]

Hi,

I am wondering if there is something inherently wrong with libkowmf that need
a rewrite from scratch ? From the look of it, it allready allows parsing,
rendering and converting to a different file format. I don't think there
would be an issue to extract libkowmf from KOffice and use it as an external
dependency.

--
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Tuesday 07 October 2008 08:38:09 pm Cyrille Berger wrote:
> I am wondering if there is something inherently wrong with libkowmf that
> need a rewrite from scratch ? From the look of it, it allready allows
> parsing, rendering and converting to a different file format. I don't think
> there would be an issue to extract libkowmf from KOffice and use it as an
> external dependency.
Note that libkowmf only does WMF and my code only does EMF. They are similar,
but not the same.

Converting libkowmf to do EMF was a possibility. I looked at the code, and
found there are a few things that I didn't like, but GPL (instead of LGPL)
looked the hardest to fix. Technical concerns were to do with the
architecture (I really wanted to split out the parsing and rendering) and
lack of sufficient WMF test cases to support safe refactoring.

Note that I'm not asking you to use it, just making it known that the code
exists.

Brad

_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Tuesday 07 October 2008 08:55:43 pm Brad Hards wrote:
> Note that I'm not asking you to use it,
missing "instead of libkomwf" here.

Brad

_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Tuesday 07 October 2008, Brad Hards wrote:
> One of those projects might be of interest to KOffice though - an Enhanced
> Metafile parser / renderer.

FWIW, Laurent and I wrote an EMF parser/renderer for a commercial customer,
so, well, we have some experience with this. In particular I'm expert on the coordinate
system monstrosity that is necessary for proper EMF rendering... I'm not sure how
much it's worth me investing time into EMF parsing/rendering for KDE (compared to
kio or konqueror), but if you have questions I'm here. I should also try to convince
the customer to let us LGPL the code we wrote for them...

--
David Faure, faure@..., sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel