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

List:       koffice-devel
Subject:    Re: The road goes ever on
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-10-30 17:10:01
[Download RAW message or body]

On Wednesday 30 October 2002 4:02 pm, Dirk Schönberger wrote:
[...]
|
|  > | 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 ;)

Have you every used Fiery RIP?

Or let me aks you in different way:  why Alpha (RISC) processor is so popular 
among RIP manufacturers?

|
|  > 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)

I think there are two reasons why Qt doesn't support more sophisticated 
rendering API:
* such API will have to be implemenetd on Windows, which is *painful*
* limited resources  (and no request for such features from customers who 
*pay* money for Qt)
AFAIK Lars and Harri were working on different parts of SVG renderer/QPainter.
I am not sure how many people, except them, are hacking on QPainter at 
TrollTech.

|
|  > 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.

Yes, existing code should be reused ;-)

|  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.

I agree. 

|  > 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 again mixing *file format* and *programming language*.
PS is *language*, PDF is ... somewhat unclear, derivative of PS with some "new 
features".
SVG is rather clean implementation of data set in XML form.
You can process XML with Qt3, expat, libxml2. 
But you can't process PS files with any of thos elibraries. You need GS for 
PS.

|
|  > 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 ;)

I just pointed out to this format, as it is:
a) available
b) open-source (in fact, BSD-like license)
c) there is a converter from SVG->MVG, and from WMF-> MVG
d) renderer is available, too.

It's up to you to take a look on it, or to send my mail to trash ;-)

|
|  Regards
|  Dirk
|  _______________________________________________
|  koffice-devel mailing list
|  koffice-devel@mail.kde.org
|  http://mail.kde.org/mailman/listinfo/koffice-devel

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

_______________________________________________
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]