Emf libray

Ok, where to start this...

Yesterday, I committed a library called qemf to koffice/libs, which reads and
handles MS Extended MetaFiles.

Today there was an email from Thomas and some discussion on IRC.  It's not
often that we have a new library, so there is no written rules about how to do
it.  It was agreed that the library stays in, and we have a discussion here on
the ML.

There are 3 questions:
1. Does this library belong in KOffice?
2. Should the name be koemf instead of qemf?
3. What is the right place for it.

1. I think it does. There are already several similar libraries in koffice:

  - kowmf
  - pigment
  - liboofilter
  - libppt

They are similar in the sense that they handle datatypes in a generic way that
could potentially be useful outside of koffice.  However we keep them in here
to have control and because it's so much more work to do it externally.  
Remember, for instance, the problem we had with syncing releases of the wv2
library with our own releases. I for one am not going to be the maintainer of
an eternal library.

2. I originally named it qemf because it implements a qt based EMF library and
uses nothing KOffice specific.  The KOffice specific things are kept inside
the emfshape.  I have no attachment to the name and would be ok with the name
koemf even if  think it would be a bit misleading.  Other alternatives would
be libemf or emflib which would be similar to libppt in filters/kpresenter/.

3. Most of the libraries mentioned in point 1 above are under filters/.  
However, in this case the first user of the library will not be a filter, but
a shape under plugins/. We could put the library in plugins/ which would be ok
for now. But I expect that there will soon be a filter that converts an EMF to
either SVG or ODG.  That would not even be pretty simple to do. So in that
case, we would have to move it.  Not a big deal, but why not put it in libs
directly?  I don't have a strong opinion on this, so any way is fine with me.

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

[Boudewijn Rempt]

On Sunday 25 October 2009, Inge Wallin wrote:

> 2. I originally named it qemf because it implements a qt based EMF library
>  and uses nothing KOffice specific.  The KOffice specific things are kept
>  inside the emfshape.  I have no attachment to the name and would be ok
>  with the name koemf even if  think it would be a bit misleading.  Other
>  alternatives would be libemf or emflib which would be similar to libppt in
>  filters/kpresenter/.

libemf sounds good.

> 3. Most of the libraries mentioned in point 1 above are under filters/.
> However, in this case the first user of the library will not be a filter,
>  but a shape under plugins/. We could put the library in plugins/ which
>  would be ok for now. But I expect that there will soon be a filter that
>  converts an EMF to either SVG or ODG.  That would not even be pretty
>  simple to do. So in that case, we would have to move it.  Not a big deal,
>  but why not put it in libs directly?  I don't have a strong opinion on
>  this, so any way is fine with me.

I think libs is fine. It isn't like the libraries in libs are all used by all
applications; it's the collection of libraries we maintain that are used by
two or more koffice components. If you want to pick nits, it could be argued
that first putting in under the shape, and then move it when the filter is
committed, but I don't think that's necessary.

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 13:49:43 Inge Wallin wrote:

> Ok, where to start this...
>
> Yesterday, I committed a library called qemf to koffice/libs, which reads
>  and handles MS Extended MetaFiles.
>
> Today there was an email from Thomas and some discussion on IRC.  It's not
> often that we have a new library, so there is no written rules about how to
>  do it.  It was agreed that the library stays in, and we have a discussion
>  here on the ML.
>
> There are 3 questions:
> 1. Does this library belong in KOffice?
> 2. Should the name be koemf instead of qemf?
> 3. What is the right place for it.
>
> 1. I think it does. There are already several similar libraries in koffice:
>
>   - kowmf
>   - pigment
>   - liboofilter
>   - libppt
>
> They are similar in the sense that they handle datatypes in a generic way
>  that could potentially be useful outside of koffice.  However we keep them
>  in here to have control and because it's so much more work to do it
>  externally. Remember, for instance, the problem we had with syncing
>  releases of the wv2 library with our own releases. I for one am not going
>  to be the maintainer of an eternal library.
>
> 2. I originally named it qemf because it implements a qt based EMF library
>  and uses nothing KOffice specific.  The KOffice specific things are kept
>  inside the emfshape.  I have no attachment to the name and would be ok
>  with the name koemf even if  think it would be a bit misleading.  Other
>  alternatives would be libemf or emflib which would be similar to libppt in
>  filters/kpresenter/.
>
> 3. Most of the libraries mentioned in point 1 above are under filters/.
> However, in this case the first user of the library will not be a filter,
>  but a shape under plugins/. We could put the library in plugins/ which
>  would be ok for now. But I expect that there will soon be a filter that
>  converts an EMF to either SVG or ODG.  That would not even be pretty
>  simple to do. So in that case, we would have to move it.  Not a big deal,
>  but why not put it in libs directly?  I don't have a strong opinion on
>  this, so any way is fine with me.

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.

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

On Sunday 25 October 2009 13:49:43 Inge Wallin wrote:
> 3. Most of the libraries mentioned in point 1 above are under filters/.
> However, in this case the first user of the library will not be a filter,
>  but a shape under plugins/. We could put the library in plugins/ which
>  would be ok for now. But I expect that there will soon be a filter that
>  converts an EMF to either SVG or ODG.  That would not even be pretty
>  simple to do.

Argh!  This should of course be "it *would* even be pretty simple".  I started
to write "it would not even be very difficult", but then changed it.
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 14:04:04 jaham@... 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.

2. EMF is not actually a vector format intended for editing, at least not as
far as I understood it.  It's more close to postscript than SVG in that sense.  
So the people who want to edit EMF's are likely not that many.  Import to
other formats for programs that can't handle EMF is of course valid, but
that's not my main concern right now.

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.

And last, I made a mistake in my wording, as I wrote in another mail.  I don't
think it's difficult, that was just the remains of some old wording that got
partly changed.
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 14:02:52 Boudewijn Rempt wrote:
> On Sunday 25 October 2009, Inge Wallin wrote:
> > 2. I originally named it qemf because it implements a qt based EMF
> > library and uses nothing KOffice specific.  The KOffice specific things
> > are kept inside the emfshape.  I have no attachment to the name and would
> > be ok with the name koemf even if  think it would be a bit misleading.
> > Other alternatives would be libemf or emflib which would be similar to
> > libppt in filters/kpresenter/.
>
> libemf sounds good.

Actually I hate it when the Gnomes do that.  Calling it lib<foo> suggests that
it's a basic library usable by anybody and when you do that and base it on
Gtk+...  But I suppose that as long as it's inside KOffice it's fine.
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 14:21:26 Inge Wallin wrote:

> On Sunday 25 October 2009 14:04:04 jaham@... 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 understand that you may have timelines to meet, but imho thats no valid
reason for things concerning KOffice as a community. Or is that how external
paid work is going to be handled in the future?

>
> 2. EMF is not actually a vector format intended for editing, at least not
>  as far as I understood it.  It's more close to postscript than SVG in that
>  sense. So the people who want to edit EMF's are likely not that many.
>  Import to other formats for programs that can't handle EMF is of course
>  valid, but that's not my main concern right now.

Can you point me to a source supporting that assumption?

>
> 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.

Well that is a valid reason.

>
> And last, I made a mistake in my wording, as I wrote in another mail.  I
>  don't think it's difficult, that was just the remains of some old wording
>  that got partly changed.

Ok understood.

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

[Cyrille Berger]

On Sunday 25 October 2009, Inge Wallin wrote:
> 2. I originally named it qemf because it implements a qt based EMF library
> and uses nothing KOffice specific.  The KOffice specific things are kept inside
> the emfshape.  I have no attachment to the name and would be ok with the
> name koemf even if  think it would be a bit misleading.  Other alternatives
> would be libemf or emflib which would be similar to libppt in
> filters/kpresenter/.

I don't think koemf is misleading. One of the goal of KOffice 2 is to build,
maintain and distribute a set of libraries usefull for Office related work. So I
think koemf would be a clear link to that set of libraries.
I think that would be more clear when (if?) we have the kofficelibs module.

> 3. Most of the libraries mentioned in point 1 above are under filters/.
> However, in this case the first user of the library will not be a filter,
>  but a shape under plugins/. We could put the library in plugins/ which
>  would be ok for now. But I expect that there will soon be a filter that
>  converts an EMF to either SVG or ODG.  That would not even be pretty
>  simple to do. So in that case, we would have to move it.  Not a big deal,
>  but why not put it in libs directly?  I don't have a strong opinion on
>  this, so any way is fine with me.

I am of the opinion to move when it is needed. We might as well end-up never
have the SVG filter, or no one will do a okular emf generator, or someone will
do okular generator that use flake to load all koffice supported document, or...
And moving is cheap.

I think it's important that we keep koffice/lib a comprehensive set of library.

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

[Cyrille Berger]

On Sunday 25 October 2009, Inge Wallin wrote:

> On Sunday 25 October 2009 14:04:04 jaham@... 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@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 14:47:24 jaham@... wrote:

> On Sunday 25 October 2009 14:21:26 Inge Wallin wrote:
> > On Sunday 25 October 2009 14:04:04 jaham@... 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 understand that you may have timelines to meet, but imho thats no valid
> reason for things concerning KOffice as a community. Or is that how
>  external paid work is going to be handled in the future?

That is a bit low.  What I'm offering is a piece of working software.  If you
or anybody else wants to generalize that I'm not against it.  But I don't have
time to do it.  What you're saying here is that no functionality is better
than limited functionality.  Note that I was not going to do a bad design or
anything, just that it wouldn't be the full generalized solution

> > 2. EMF is not actually a vector format intended for editing, at least not
> >  as far as I understood it.  It's more close to postscript than SVG in
> > that sense. So the people who want to edit EMF's are likely not that
> > many. Import to other formats for programs that can't handle EMF is of
> > course valid, but that's not my main concern right now.
>
> Can you point me to a source supporting that assumption?

No, as I said, it's just my basic understanding and feeling.  if you have
other information, I'm can easily change my mind.
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

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@... 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@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 15:02:55 Cyrille Berger wrote:
> On Sunday 25 October 2009, Inge Wallin wrote:

> > 3. Most of the libraries mentioned in point 1 above are under filters/.
> > However, in this case the first user of the library will not be a filter,
> >  but a shape under plugins/. We could put the library in plugins/ which
> >  would be ok for now. But I expect that there will soon be a filter that
> >  converts an EMF to either SVG or ODG.  That would not even be pretty
> >  simple to do. So in that case, we would have to move it.  Not a big
> > deal, but why not put it in libs directly?  I don't have a strong opinion
> > on this, so any way is fine with me.
>
> I am of the opinion to move when it is needed. We might as well end-up
>  never have the SVG filter, or no one will do a okular emf generator, or
>  someone will do okular generator that use flake to load all koffice
>  supported document, or... And moving is cheap.
>
> I think it's important that we keep koffice/lib a comprehensive set of
>  library.

Hehe, are you aware that comprehensive means broad and all-covering?  :-)
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

On Sunday 25 October 2009 15:51:26 Inge Wallin wrote:

> On Sunday 25 October 2009 14:47:24 jaham@... wrote:
> > On Sunday 25 October 2009 14:21:26 Inge Wallin wrote:
> > > On Sunday 25 October 2009 14:04:04 jaham@... 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 understand that you may have timelines to meet, but imho thats no valid
> > reason for things concerning KOffice as a community. Or is that how
> >  external paid work is going to be handled in the future?
>
> That is a bit low.  What I'm offering is a piece of working software.  If
>  you or anybody else wants to generalize that I'm not against it.  But I
>  don't have time to do it.  What you're saying here is that no
>  functionality is better than limited functionality.  Note that I was not
>  going to do a bad design or anything, just that it wouldn't be the full
>  generalized solution

I am sorry if i have offended you. That was not my intention. I only wanted to
say that your deadline shouldn't be a factor on how we handle that lib. Don't
you agree with that?

>
> > > 2. EMF is not actually a vector format intended for editing, at least
> > > not as far as I understood it.  It's more close to postscript than SVG
> > > in that sense. So the people who want to edit EMF's are likely not that
> > > many. Import to other formats for programs that can't handle EMF is of
> > > course valid, but that's not my main concern right now.
> >
> > Can you point me to a source supporting that assumption?
>
> No, as I said, it's just my basic understanding and feeling.  if you have
> other information, I'm can easily change my mind.

Well at least for Kivio I think it would be essential to be able to edit
wmf/emf content as many stencils from e.g. Visio are in these formats. And
users probably want to use and edit them as well.

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

In my opinion the advantages of the new library out-weight its critics. Note
that it is a work in progress and that the way it is going to be used in the
immediate future (for *displaying* rather than converting) has no negative
impact in the long run of KOffice because it would be just a matter of
designing a new filter and deprecating the display-only shape.

The concerns that were raised because it's a needed feature that was paid for,
are, well, low. If Inge hadn't said that it was for a paid project, probably
the same concern would have been raised, but would likely have been met with
the saying "who codes decides" and nobody would have argued that reduced
functionality is better than no functionality at all, specifically when the
reduced functionality doesn't incur in data loss for the user nor limits the
the "right way" to be archived in the future.

I do have to point out that I really think that a raster-format-unified shape
and a vector-unified shape; or, if possible, a unified image shape that
selects the proper vector or raster based shape without bothering the user
with details is very desirable. Yet, can wait for now.

So, all in all, I'm in favor for the inclusion of the new library in KOffice.

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

On Sunday 25 October 2009 20:18:07 Carlos Licea wrote:

> In my opinion the advantages of the new library out-weight its critics.
>  Note that it is a work in progress and that the way it is going to be used
>  in the immediate future (for *displaying* rather than converting) has no
>  negative impact in the long run of KOffice because it would be just a
>  matter of designing a new filter and deprecating the display-only shape.
>
> The concerns that were raised because it's a needed feature that was paid
>  for, are, well, low. If Inge hadn't said that it was for a paid project,
>  probably the same concern would have been raised, but would likely have
>  been met with the saying "who codes decides" and nobody would have argued
>  that reduced functionality is better than no functionality at all,
>  specifically when the reduced functionality doesn't incur in data loss for
>  the user nor limits the the "right way" to be archived in the future.

Well the point was that it being a paid for project should not be a reason to
handle it different than other (non paid) work being done.

Ciao Jan

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

On Sunday 25. October 2009 13.49.43 Inge Wallin wrote:
> Yesterday, I committed a library called qemf to koffice/libs, which reads
> and handles MS Extended MetaFiles.
[]

First of all, thanks Inge for writing this email. I think its a good idea to
open the topic to the mailinglist whenever something is done that affects the
community or the general direction of koffice :)

From the mails here I understand that the new library is currently only used
by the shape. The goal of the shape is to allow an emf to be loaded and
saved without loss.
Getting this shape done *now* is important for the project Inge is getting
payed for and therefor a filter to convert the emf to native KOffice shapes is
not on the agenda.

I have to agree with various voices that putting this in koffice libs is over-
designing things when there is only one user (the shape).
I want to add the observation that the only other user, the filter, could
very well replace the shape altogether. If we follow the suggestion Jan made
with a grouping shape.
Last technical point of putting it in the libs; if you look in
koffice/libs/NAMING and read techbase for libraries (or read ebn's list of
errors) you'll notice that there are a lot more things to prepare when you
put these classes in a public library. Exported symbols, d-pointers,
renaming classes etc etc etc.

There is one more pressing point that I'd like to bring up; we keep wv2
outside of KOffice tarballs because the software freedom lawcenter put out
an advisory on the license under which the file formats can be used. The EMF
file format is licensed under the same license, so the decision made a long
time ago should apply to this new code too, I don't see any reason why it
should not apply, do you?

The suggestion of having a new shape that shows vector and text, but
doesn't know about our vector or text editing feature still feels wrong. And
I'm concerned with your reasons. Roundtripping sounds like a really bad
design decision for going read-only. Did you notice that we need either a
MSWord or Powerpoint exporter? Both of them are non existent. As your
other motivator was speed, writing that is out of the question and thus your
points are conflicting.

In the end, you decide what to write and how you write it. I think working
on the filter will get you results faster, but thats your decision.

I do see a lot of people here that agree that this new library should not be
a library in koffice/libs. Its likely a much better idea to place it as a
subdir of your shape, making the plugin and the emf code one plugin. One
.so file.
How about that?

Slightly off topic;
A lot of people have suggested we start to use git because we want to avoid
importing unfinished projects into trunk. I think Boudewijn has suggested
this various times and I fully agree.
When we last discussed this (in Amsterdam) everyone agreed this could go
to playground and integrate when ready (after a review here on the list).
This is how plasma and amarok are doing things and it works great for them.

Now, I guess there was some miscommunication since the emf dir was
already in playground. I'm not sure why you moved it into koffice.
Developing things in playground works just fine, I've written some apps
myself using only the installed headers. Works great. So what about leaving
the shape to mature there?

How do others think about that?
--
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

[jos.van.den.oever]

Here's my take on this. First short answers then a bit of explanation.

On Sunday 25 October 2009 13:49:43 Inge Wallin wrote:
> There are 3 questions:
> 1. Does this library belong in KOffice?
yes, but as a shape plugin, not as a library

> 2. Should the name be koemf instead of qemf?
does not matter

> 3. What is the right place for it.
inside the filter shape plugin

> 1. I think it does. There are already several similar libraries in koffice:
>   - kowmf
general library used in mswriteexport and wmfimport

>   - pigment
>   - liboofilter
liboofilter is never compiled at the moment.

>   - libppt
libppt is a static library, it is linked into libpowerpointimport.so and only
useful for importing ppt files.

wmf support is now written by Inge as a shape. There is time pressure so
making a nice shared library for more general use of wmf is not possible. Why
not statically link the code into a shape like ppt support is linked
statically into a converter plugin?

Writing clean code is still important and when there is time to add emf write
support the code can still be refactored into a shared library.

Cheers
Jos


--
Jos van den Oever, software architect
[phone]
http://kogmbh.com/legal/
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel

[Thorsten Zachmann]

Hello Inge,

On Sun October 25 2009, Inge Wallin wrote:

> Ok, where to start this...
>
> Yesterday, I committed a library called qemf to koffice/libs, which reads
>  and handles MS Extended MetaFiles.
>
> Today there was an email from Thomas and some discussion on IRC.  It's not
> often that we have a new library, so there is no written rules about how to
>  do it.  It was agreed that the library stays in, and we have a discussion
>  here on the ML.
>

I will write one reply only as already quite a lot have been said.

My personal preference is that all the code needed for the emf shape to be in
the shape itself.

> 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 have the same concerns already raised by Jan and Cyrille. I prefer to do
things the right way instead of just doing them. In the end it will save much
more time and will create a better user experience. Putting all inside the
shape will limit the problems.

> 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.

This can be best reached via a vector shape. It can be saved inside a frame
which allows also other representation e.g. a pixmap, with that also other
apps not supporting emf can view it.
A vector shape can keep its original data and save it back to file without any
modification. When the vector shape is edited it can be saved as svg and it
original data can be removed. If we had such a design it will be very easy it
add support for new vector formats.

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

On Sunday 25 October 2009 13:49:43 Inge Wallin wrote:

> Ok, where to start this...
>
> Yesterday, I committed a library called qemf to koffice/libs, which reads
>  and handles MS Extended MetaFiles.
>
> Today there was an email from Thomas and some discussion on IRC.  It's not
> often that we have a new library, so there is no written rules about how to
>  do it.  It was agreed that the library stays in, and we have a discussion
>  here on the ML.
>
> There are 3 questions:
> 1. Does this library belong in KOffice?
> 2. Should the name be koemf instead of qemf?
> 3. What is the right place for it.

A lot has been said about this, and I think it's time to wrap up.  Is anybody
unhappy with the following summary?

1. mostly yes, at least it is ok.
2. qemf is perhaps not such a good name.  koemf is better, or even libemf.
3. For now, let's keep it out of libs/ and put it under the shape that uses it
instead.  It can always be moved if there are more users.

Regarding the shape, we all agree that a general vector shape is better, but a
good enough start is a dedicated EMF shape. It can be generalized later.

Ok?

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

[jos.van.den.oever]

On Monday 26 October 2009 11:38:25 am Inge Wallin wrote:

> On Sunday 25 October 2009 13:49:43 Inge Wallin wrote:
> > Ok, where to start this...
> >
> > Yesterday, I committed a library called qemf to koffice/libs, which reads
> >  and handles MS Extended MetaFiles.
> >
> > Today there was an email from Thomas and some discussion on IRC.  It's
> > not often that we have a new library, so there is no written rules about
> > how to do it.  It was agreed that the library stays in, and we have a
> > discussion here on the ML.
> >
> > There are 3 questions:
> > 1. Does this library belong in KOffice?
> > 2. Should the name be koemf instead of qemf?
> > 3. What is the right place for it.
>
> A lot has been said about this, and I think it's time to wrap up.  Is
>  anybody unhappy with the following summary?
>
> 1. mostly yes, at least it is ok.
> 2. qemf is perhaps not such a good name.  koemf is better, or even libemf.
> 3. For now, let's keep it out of libs/ and put it under the shape that uses
>  it instead.  It can always be moved if there are more users.

Static linking would be best. Do you mean you will link the library
statically?

Cheers,
Jos


--
Jos van den Oever, software architect
[phone]
http://kogmbh.com/legal/
_______________________________________________
koffice-devel mailing list
koffice-devel@...
https://mail.kde.org/mailman/listinfo/koffice-devel