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

List:       koffice-devel
Subject:    Re: Emf libray
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2009-10-25 14:56:51
Message-ID: 200910251556.51868.inge () lysator ! liu ! se
[Download RAW message or body]

On Sunday 25 October 2009 15:08:51 Cyrille Berger wrote:
> 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.

"In a hurry" here doesn't mean rigid and bad design.  It means "one step to 
the full solution".  Another example that I have come across recently is our 
page layout code.  From the start it has been missing both borders, padding, 
and shadows, but it was fine anyway because what it did it did well.  Same 
thing here.

> > 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 ?"

I would be fine with that, except I'd have to write the conversion code.  I'll 
check that solution on monday. 
_______________________________________________
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]