From: shaheed <sr...@ie...> - 2001-09-11 19:14:00
|
Ewald, > Oh yes, now I remember :( > You are right, we use the QPicture internal format in the store, because > the WMF support is currently for loading only, not for writing. This goes right to the heart of why I wrote the third WMF implementation in koffice. Most existing WMF implementations were geared to converting WMF (essentially a vector format) into an image of some kind (effectively a non-editable format). My philosphy for the kwmf code was to (a) write a parser and (b) write output routines which preserved the vector format. Now, you have a simlar decision to make for the RTF filter. [ Aside: note that one could argue a semantic difference between an inline WMF, and an embedded WMF, converting the former to an image and the latter to an embedded vector graphic. The msword filter has both sorts of code, but my current thinking is to prefer the vector form for all cases ]. > Well, this sounds stupid, we could simply save the original WMF data.... > the only problem is that it means storing it in addition to the QPicture. > Currently we only keep the QPicture in memory, from which we can't find > the WMF back...... However if using a normal image format is more important > than the memory loss, I guess we could store the WMF data in memory besides > the QPicture, and save that to the store. Well, actually, I don't see the point of saving WMF. If we want to preserve the vector form, we should do so in a form which is editable by a Koffice app, i.e. kontour. > I wonder if libwmf2 will help about this... Shaheed ? My belief is that libwmf2 hasa much more complete item (a) than I ever dreamt of implementing, and I think it has at least one (b). All we need is another (b) for kontour. And if I have not convinced you that the vector form is the way to go (:)) and all you want is non-editable clipart, then libwmf2 certainly has output to PNG. I would use that! Thanks, Shaheed |