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

List:       koffice-devel
Subject:    Re: The road goes ever on
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-10-29 19:00:46
[Download RAW message or body]

> Let's take, for example, high-quality and small in size image (attached,
> web-spider-rsvg.png). It is 23K.  I generated it using librsvg-2.1.1, from
> SVG file (4.4K, it is also attached).

> I have tried several paths to convert this image to PS (EPS is PS with
> bounding box).

> 1) First I converetd it using latets stable release of Imagemagick
(5.5.1):
> .....

Ouch. I think I understand what you did, but I still don't think it is the
right tool for the job.
The idea behind what you did is using EPS as some kind of "container" for
the actual image / bitmap data. This is possible, but it should only used
for outputting to a real Postscript printer. You don't convert the image
data to vector data, but instead convert the image data from its compressed
form as PNG to an uncompressed form which is uncompressed form useable by a
printer.

This way is also done by the other tools you mentioned.

For conversion to vector data you need more specialized tools, like e.g.
Adobe Streamline or something like the Open Source "autotrace" project
(somewhere on sourceforge, IIRC.

> |
> |  I don't think Ghostscript is the right tool for this job, because its
main
> |  goal is mostly reversed, i.e. the conversion of vector data /
Postscript
> |  calls to a rendered image.

> GS is not "right tool" for any task, but until we have couple of good SVG
> renders compliant with SVG 1.1, and QT patched to produce SVG instead of
PS
> (WSVGprinter class), we need to "live with GS".

What do you want to achieve? From what I understand, SVG is more suited to
"clip art", i.e. one page, or a small area thereof, similar to EPS. Real
Postscript files mostly contain multiple pages.
I think Karbon14 contains a nice substitute for a SVGPrinter class, but this
implies using Karbon's VPainter API instead of QPainter.

> |  For WMF support, what is the state of support of WMF in QPicture?
> | QPicture's goal seem to be a similar goal as WMF, i.e. a meta file
format
> | containg render API calls.

> Forget about Qt for Vector graphics.
> AFAIK Qt is limited by QPainter, so you can't expect from QT something
which
> exceeds its capabilities.
> That's why there is a KSVG, while Qt3 has support for (rudimentary in
> complexity) SVG files.
> This question has been asked, and Trolls answered that they are not going
to
> provide reference SVG implemenattion inside QT3.

Again, I think Karbon provides a nice rendering model similar to Postscript
/ PDF and SVG. The problem is, that the Karbon developers have not enough
free resources to use the VPainter API outside of the actual Karbon. Please
feel free to evaluate the API and nag the Karbon developers, like Rob Buis,
for feature enhancements. Please be prepared to get told "do it yourself :)"

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]