[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Emf libray
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2009-10-25 14:08:51
Message-ID: 200910251508.52062.cberger () cberger ! net
[Download RAW message or body]

On Sunday 25 October 2009, Inge Wallin wrote:
> On Sunday 25 October 2009 14:04:04 jaham@gmx.net wrote:
> > So the reason you want the library to live in /koffice/libs is the emf
> >  shape, which several people already pointed out is not the proper way to
> >  go. Actually I am not sure why you assume that converting emf to vector
> >  shapes is difficult to do. Granted it is some more work than simply
> > using the code already there to paint the emf primitives to a pixmap and
> > just displaying that. But if you actually had looked at the wmf import
> > filter, is is no black magic involved at all to convert to vector shapes.
> 
> Let me clarify this a bit.  I am all for creating a generic vector shape
>  that can handle more than one feature.  So why am I not doing it?
> 
> 1. Time.  I'm doing this as part of the n900 project and we are very
>  stressed already.  In the future I may work on creating a more generic
>  vector shape and when it's ready I'll be happy, but not right now.  I
>  thought that being able to show EMF's would be better than not for the
>  time being.
I am with Jan there. Not a good argument, I understand that you are in hurry 
for the n900 project, that's fine, but then there is nothing wrong in having an 
external plugin that fit the n900 project need. But *we* should not bloat koffice 
with things written in a hurry, we will end up maintaining it in the years to 
come. I believe that being in a "hurry" is one of the reason OpenOffice has 
grown to be the monster it has become, I would vote for clean.

> 3. Roundtripping. The main reason for the existence of this at all is so
>  that people will be able to read MS Office files, edit them a little and
>  save back to an MS format with as little data loss as possible. As you
>  pointed out yourself, conversion sometimes leads to data loss, which we
>  want to minimize.
What about loading the EMF file in a group shape, and add a binary annotation 
to that group containing the EMF file (or a URI), and use that annotation when 
saving back ? And when the user try to edit that group, have a message to the 
user saying "carefull, editing the content of this group might lead to round 
trip error, are you sure you want to continue ?"

-- 
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]