[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-30 13:02:59
[Download RAW message or body]

> |  My prefered work is around real vector images, so I tried to show you
my
> |  prefered tools ;)

> ok, I have never used Latex, so Iguessed that EPS files are the only files
> supported by it.
> As about "real vector images" - I guess we speak about SVG files, right?..

Yes and no. Basically, a "real vector image" use operations to define vector
path, which later are rendered by the imager (imaging, the verb). Basic
operations for
this path definitions are

- begin a path
  EPS: 100 100 moveto
  SVG: M 100 100

- add a line segment
  EPS: 100 100 lineto
  SVG: L 100 100

- add a bezier segment
  EPS: 100 100 110 100 100 110 curveto
  SVG: C 100 100 110 100 100 110

( this is for all supported segment types, like arcs )

- close the path
  EPS: closepath
  SVG: Z

So basically SVG and PS/EPS support the same rendering model, modulo a quite
different syntax. SVG has also some extensions, EPS doesn't support, like
transparency.

> |  I want to use vector data not out of fun, but because to be able to
later
> |  change the data (recolor, change the resulting paths). Your proposed
> | process would create not especially useable vector data, not to speak
from
> | the performance hit while rendering :)

> To be fair, what I proposed is *good solution*.
> FYI: Adobe calls such thing "gradient mesh" (in Adobe Illustrator 9/10)
> You can do *a lot of things* with gradient meash.  I think there are some
> "Effects" plugins for AI, which can apply effects using vector
> transformations *on gradient mesh*!

It may be a good solution if the amount of needed "mesh points" is
relatively little, like a 10x10 gradient mesh. It doesn't scale well to say
a rendered A4 image in 600 DPI (8 x 600 x 11 x 600 -> ca. 31.6 million small
rectangles take a while to render ;)

> As about performance - if you are satisfied with GS performance, you
wouldbe
> ok with gradient meshes like this, too.
> Seriously: if you have 1GHz Pentium III, or Athlon 2100XP+ - how do you
> suppose to spend extra cycles? :-)
> I propose to spend them on stransparency/alpha channle, and numerous
> gradients in SVG-based UI/icons/widgtes :-))
I am fine with alpha channel and gradients. I am not quite sure if widgets
should be implemented using this render method. The rendering model resolves
around a
non-fixed resolution with floating point parameters. It is rather difficult
to get pixel correct renderings in this model (according to a thread on
qt-interest this was also the main reason Qt doesn't support a more
elaborate rendering API)

> But let's make fair analysis.
> 99% of printer do not support PostScript. And still all Linux users print
on
> thos eusers, using GhostScript/CUPS.
> Replace GS/CUPS with SVG-based rendering model/renderer, and that's it.
> May be, CUPS can be extended via some plugin to support such renderer, and
> SVG MIME type.

You are right, at least in theory. I think, however, there is a small focus
problem. At
least currently KDE is still a desktop environment, so it should provide an
interface to the underlying system, not define basic systems for itself.
The basic rendering models of Postscript / EPS and SVG are similar, so I
think for the time being the underlying foundation a la GS and CUPS should
be used.
If it will become necessary to support the more advanced features of SVG,
like transparence, it is still time to re-evaluate.
Besides, it is still possible to do client-side rendering via libart into a
QImage, and sending this image to the printer.
But this should be a real last solution.

> |
> |  For displaying of multipage documents on screen you may also consider
PDF.

> Which is PS based.
> I think PDF needs to be replaced.  It is not *open* (and PS is owned by
Adobe,
> too).
> SVG seems to be W3C standard. So we are on a *safe way* whneuse SVG.

I think we have still time for this. I think it is more important to be
aquainted with the underlying rendering model and the way of thinking (i.e.
see pixel correct rendering as an exception instead of the rule). If you
achiee that, choosing between PS, SVG and PDF is just a matter of choice,
because these are just different expressions of the same basic concepts
(perhaps suited to different uses)

> I think you may want to take a look at MVG (Magick Vector Graphics), part
of
> ImageMagick.
> MVG is internal SVG-based format, used by IM.
> It's basically "streamed" SVG, so you don't nedd to parse XML (and no need
for
> "pasring" phase in SVG processing, youy can start rendering immediately)

Technically nice, but currentyl useless to me. I am not in need of yet
another not suppoerted Ad Hoc file format, thank you ;)

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]