From koffice-devel Wed Oct 30 08:49:56 2002 From: =?iso-8859-1?Q?Dirk_Sch=F6nberger?= Date: Wed, 30 Oct 2002 08:49:56 +0000 To: koffice-devel Subject: Re: Vector format/metafile for KOffice (Re: [Karbon14] misc) X-MARC-Message: https://marc.info/?l=koffice-devel&m=103596782011129 > I think another level of abstraction is needed, I would say - *required*, > here. let's forget about numerous often incompatible vector and semi-vector > formats floating around. It's really not necessary to have different formats all > together, and provide diffferent rasterization methods for those. Maybe I am nitpicking, but I think there is a distinction between a "meta file format" and an "exchange format". A meta file format is tied to a special rendering aproach, be it WMF for Windows GDI or EPS for the Postscript rendering model. An exchange format tries to be rendering independent. The current recommended exchange file format seems to be SVG, but IMHO it is rather biased to the Postscript rendering model, which isn't natively supported widely (beside things like MacOSX and the different Display Postscript /DPS / DGS implementations). So it is not really easy to provide SVG support, because you basically have to provide a Postscript (and descendants) compatible rendering model on your target system. > I think KOffice should use one common Vector Metafile format (which *can* have > raster images inside as well, BTW). > There is no need to reinvent the wheel. > SVG has all necessary features of such metafile format, and even more. I would like to see this, to, but I see some problems in this, at least currently. - KOffice (at least the applications beside Karbon) use an rendering API which is quite incompatible / not enough powerful for native SVG support - the SVG support in Karbon and SVG is dispersed, you have multiple copies of libart for rendering and multiple SVG parser implementations. There would have to be a concerted effort to provide a single package, hopefully containing a libart version, a VPainter for the render API definition and a SVG reader / writer implementation. This package should be part of koffice / kdelibs or and own package, a la arts. It should be used from all project parts which use the advanced APIs or SVG. No more private libart copies all over the place. > So, I think following should happen: > a) SVG inserted into KWord doc is saved as SVG, without conversion/dta loss. > b) WMF or EMF inserted into KWord/KOffice converted automatically to SVG, > and saved as SVG. > c) when document is exported from KWord to MS Word .doc format -> SVG is > converted to WMF or EMF (checkbox in Export as MS Word dialog) To stay in the current KOffice framework, I would start with a KoPictureSVG, which stores the SVG data and is rendered on demand. If the above mentioned step to an advanced API is taken, you can define a more natie meta file format, which renders to a VPainter directly, instead of rendering to an QPixmap/QImage, which is rendered by a QPainter. > | > | Is a KWord picture more sucha meta file, ore merely a QImage where the > | ector data, like EPS, isn't discarded? > I hope KWord would use SVG as metafile :-) KWord can use everything as mea file, which can render itself to a QPainter. So if a QPictureSVG exists, you have SVG metafiles. > | > | Would it be useful to be able to "export" a Karbon document to a > | "picture", and vice versa? > Karbon should export just SVG, amy be with different options for SVg details > (number of digits for floating point, use ENTITY or CSS or inline 'style' > attribute, etc.; see Adobe Illustrator SVG Export plugin/dialog for more > info) AFAIK there exist a Karbon SVG export filter. > | This would also allow that a KWord picture could contains calls for the > | more advanced VPainter API instead of the current QPainter API (if it > | really is a QPIcture) > I think this VPainter should go into kdelibs, if it is complete/as powerful, > as you say. Konqueror badly needs previewing capability for different vector > formats. And I beleive other apps (outside KOffice) would like to use such > powerful API, too. I think the API is powerful, but the current implementation seems to be limited. I would like to see a more QPainter oriented architecture, where VPainter is some kind of facade for the actual implementation, sort of like the current QPainter / QPaintDevice idea. I would like to see a QPaintDeice which emits Postscript code, to be able to use the KPrinter framework. But this is just my now 1 1/2 year old personal quest ;) I somehow don't find enoght time to provide a sample implementation for my ideas... Regards Dirk _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel