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

List:       koffice-devel
Subject:    Re: Vector format/metafile for KOffice (Re: [Karbon14] misc)
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-10-30 8:49:56
[Download RAW message or body]

> 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
[prev in list] [next in list] [prev in thread] [next in thread]