'Re: Vector format/metafile for KOffice (Re: [Karbon14] misc)'

[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:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-10-30 17:35:45
[Download RAW message or body]

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

All your statements just confirm my words that font users have no clue what 
fonts are about :-)
I will try to explain differences in a few words
                            analog in lang.  	hinting complexity	hinting tools
PS Type1		C				easy				available
TrueType		assembler		extremly difficult	limited to VTT*

* VTT == MS's Visual TrueType
So, producing TrueType font is equal in developing application in assembly 
language.
PS Tyep1 is more like using C.
There is no hinting system available equal to C++ or Modula-2 (in terms of 
results/pleasure to work in)

BTW: if you read some threads I pointed to, you will see that indeed *I 
proposed new font format*. 
For more details, check <freetype-devel> archives

|
|  > // 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 think you missed my point again.
I was speaking about hermite splines as *replacemnt* (or *add-on*) to bezier 
splines.
You can control Tension and Continuity with Hermite Splines. 
And you can't control those with Bezier splines.

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

Have you seen size of that "Batik"?
I woul dprefer to call it *elephantik* :-)
Batiks sources+ JRE == 30MB in size.  It's about  Qt3+kdelibs+kdebase in size, 
but still fall away from complete desktop.

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

They are. May be, David faure can tell a few words - I guess he has touched 
libwmf.

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

And latest version of that interpreter, called AFPL GS, is not available for 
free.
GNU counterpart appears about 1.5 years later (1.5 yars *after* release of 
AFPL GS)

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

  glibc?

|  - the actual rendering system

  libart of ImageMagick?

|  - the drivers for the different supported printers / output devices

  raster?

|  - a small toolkit for achieving multi-platform ability
|

  pardon?  

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

 yes, librsvg uses libart, as well as KSVG, Sodipodi, Karbon14, GS.
 But, FYI, libart is *gray rasterizer* (anti-aliasser).

ImageMagick has own anti-aliasing algorithm.

Freetype2 has own anti-alising algorithm, too.

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

I fit works - great. But so far, I have mixed results with PS import.
Just try to print one page from KWord and import PS files into Karbon.
It doesn't work!

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

I think a whole Java thing is bad.
Idea is great, implementation uscks.

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

And KSVG is tied to both Qt and kdelibs, which make sit absolutely unusable 
even in GTK apps. So what?

PLEASE: read my mails!  I hav etold already that it's posisble to get rid of 
gdk-pixbuf, if there is interest.

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

This one is not ready, and not shipped with KDE.

|  - koffice/karbon : Reads and writes. Creates a Karbon document, which is
|  later rendered via VPainter (rendering API) and libart (own version)

Karbon is very promising.  :-)
What about to use Karbon as KPArt in Konq?
What do we need for that?  Move VPainter/Karbon libs into kdelibs?

|  - 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 am curious: does KSVG support Japanes, Indic, Chinese, Korean?
If not - there is nothing to discuss here.

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

Except ImageMagick ;-))

I still need to see that ;-)

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

Forget about PS, it's dead. Adobe doesn't work on it anymore.
ok, you wnat PDF_based imaging model?
Yes, it's interesting. It's called Quartz in MacOS X. 

Can you do it on your own?  My applaude! Open-Source dev.model really rulez! 
:-)

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

Ah, great.

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

Check ImageMagick's Draw API (draw.h), *before* starting to code.
I think all this is already there. May be, you can reuse/share code?

I invite you to subscribe to <magick-devel>, and discuss Draw API (and its 
benefits) there.
It's low-traffic list, focused on *developemnt* iussues.

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

What about fixing VPainter than?

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

Cheers,
-- 

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] 