[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 13:40:54
[Download RAW message or body]

> Sure!
> I can tell you more: I have posted message "What is the best format for
fonts
> storage/distribution?" on <Freetype-devel> and <pfaedit-devel>
mailinglists,
> where I beleive font experts are present.
> And guess what? Most of people have no clue about differences about
storage,
> distribution, etc.  They use FT for rendering, that's it.  The rest is
done
> with some Magick Wand. :-)

I think the problem is not really technical, but merely political. From what
I understood, the (Adobe) T1 font dstribution is technically better, but
more difficult to render. (Microsoft, Apple) Truetype format is easier to
render to screen, but encumbered with ugly patents.
I don't think there is need for yet another font distribution format. Fonts
are there to be used, not necessarily to be created. You don't really want a
nice format, for which no fonts are available for use.

> // you may also want to check my posting & thread about "hermite splines",
and
> my idea to replace bezier splines with hermite splines in order to achieve
> better font rendering.  It was also of <freetype-devel> ML.

> Same is valid for vector drawings.
> There are no supporting facts that renderer should use the same format
used
> for storage, or for distribution.

I am not enough fit in the technical details to be able to say if this is
useable.
You would have to convert the outlines into the native format, before
rendering. This conversion may or maybe not a nontrivial process.

> I can just add to your very valid points that:
> a)  SVG is *renderer-independent".
> There is even Java-based SVG renderer, called Batik (see
> http://xml.apache.org/batik/)

Which is implemented relatively easy because of the existence of the Java2D
API
(which was coincidently implemented by Adobe...)

> b) you can render WMF on Linux/UNIX, using libwmf (directly), or using
Image
> Magick or KDE3.

I didn't say it is impossible, just that you have to recreate the rendering
environment to be able to use the file format. I am not sure if all
intricate parts of the GDI of several windows versions are covered.

> c) PS/EPS can be rendered on variety of platforms, but indeed you need PS
> interpreter for that.

A PS interpreter (Postscript, the language) is one necessary part, yes.

> You need to write much more code to implement PostScript (hey, PLRM is
about
> 800 pages itself!), comparing to SVG.
> GS sources are about 5MB-12MB, depending on distribution/included
packages.
> librsvg-2.1.1 is just 150K tarball, compiles in less than 1minute.

I think the actual PS interpreter is just a part of the problem of the size.
I think the size is also needed for the following:

- a library of base data types like stacks and lists
- the actual rendering system
- the drivers for the different supported printers / output devices
- a small toolkit for achieving multi-platform ability

For rsvg, I think it happens to use libart, where most of the basic
rendering is implemented.

A basic Postscript interpreter is also part of my AI importer for Karbon, so
it can't be that difficult. I just happen to stay at the "lexer" and "basic
parser" level with a fixed set of operators, instead of providing a full
level interpreter with its runtime.

> Of course, SVG renderer can be huge, too.
> Batik is about 5MB in binary form, and about 8MB in sources, plus this
> requires 19MB of JavaRE.

I think Batik just is another example of the not invented here syndrome.
They create their own implementations of basic features, like image input /
output, which doesn't decrease the size of source code the resulting
package.

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

> Very well said.
> May I ask you to take a look at librsvg?
> ftp://ftp.gnome.org/ftp/mirror/gnome.org/sources/librsvg

I tried and somehow I am not really convinced that it is useable. The
problem is that it is tied to rendering to gdk-pixbuf, which makes it not
necessarily more re-useable.

For what I remember, there are currently the following SVG parser and writer
attempts in KDE

- kdelibs: a subset of KSVG which is use for rendering SVG icons. Just
reads. Renders to libart (own version), outputs QImages(?)
- kdenonbeta/ksvg: Just reads. Renders to libart (own version), outputs
QImages. Provides a Viewer KPart
- koffice/karbon : Reads and writes. Creates a Karbon document, which is
later rendered via VPainter (rendering API) and libart (own version)
- koffice/karbon/core - reads and writes SVG path definitions from a Karbon
document. No actual rendering is done.

What is not covered is a KoPicture implementation for SVG, which would make
SVG useable as Koffice wide clipart.

> The only dependency (not very well compatible with KDE/QT) librsvg has is
> gdk-pixbuf. Plus one pango call, but I think it canbe replaced with
FreeType
> call for non-exotic language.
Pango provides Unicode rendering for the more exotic languages, think
Japanes, Indic, Chinese, Korean. I think a similar functionality is
somewhere hidden in Qt3's QPainter and QString. As usual, it is not useable
without the rest of QPainter.

> I have discussed with Dom Lachowicz (librsvg maintainer)  idea to replace
> gdk-pixbuf with something gdk-independent, called say "png-pixbuf"
> He told me that he can consider this if "KDE project has interest".
> It's time to speak up! :-)

I would somehow divide between the "parsing part" (including external
references, CSS, perhaps scripting/animation) and the actual rendering part.
The parsing part could be used between Gnome (or rather librsvg) and KDE.
The rendering part is more difficult. There exist multiple attempts to solve
the same problem, including gnome-print. All these attemps have a rather
different API with different scopes. OTOH most of them earlier or later
render to libart ;)

> |  KWord can use everything as mea file, which can render itself to a
> | QPainter. So if a QPictureSVG exists, you have SVG metafiles.

> AFAIK QPainter can't render all SVG primitives.

If you use libart to render into a pixmap/image, and output this image, even
QPainter can render all SVG primitives ;)

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

> I hope we do not need PostScript code inside KDE.
> Or, I would betetr vote for built-in Oberon or Modula-2 module for KDE,
but
> not for PostScript.
> Remember: PostScritp is *programming language*.
> I once used it to solve qudratic equiation, to demonstrate that it can be
> done.

Sorry, I think you misunderstood me. What I would like to introduce is a
standard API for rendering of graphics according to the Postscript (or
perhaps more advanced, like SVG and PDF) rendering model. For this rendering
API there should be exists multiple backends for rendering, like a
antialiased rendering via libar, perhaps a XRender based one, a Qt/QPainter
based one and one which emits Postscript code. You need the PS emitter to be
able to access the KPrinter
system, i.e. for printing to different (hardware) output devices via a
printer queue.
This would also get us PDF output functionality.

I don't plan to integarte Postscript the language into KDE, yet ;)

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

> Try simple SVG renderer, instead of PS.
> This would allow to make things *done* :-)

The renderer doesn't really interest me, and it is available in KSVG and as
a subset in kdelibs. I am more interested in the "framework part", so that
you can write (similar to the current QPainter approach)

KLibartPaintDevice device;
KPainter painter (device);

KGradient gradient;
.... fill the gradient ...

painter.moveTo (100.0,100.5);
painter.lineTo (110.5, 100.0);
painter.curveTo (100.5, 100.0, 100.25, 100.0, 200.0, 200.0)
painter.closePath();
painter.setFill (gradient);
painter.fill();

painter.showPage();

A similar code is possible with the current VPainter, but the multiple
backends are implemented using inheritance insead of delegation, which makes
it impossible to
do e.g. tap into the KPrinter system.


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]