> Sure! > I can tell you more: I have posted message "What is the best format for fonts > storage/distribution?" on and 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 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