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

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

IMHO the later Windows versions contains GDI versions GDI+, which provides
some features, which could be used for this. But these APIs are not
available in lower Windows, think Windows 98.
Or they could use líbart, but this wouldn't be possible, of course...

> * limited resources  (and no request for such features from customers who
> *pay* money for Qt)

I think this is the real reason.

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

Postscript: a programming language with runtime system and API, the "grand
parent" of the more modern APIs
PDF: a file format with a similar syntax than Postscript, but with a fixed
set of operators (instead of the programming language aspect of PS, which
allows for own operators, and the overloading of existing operators)
SVG - an XML dialoect / application for definitions of vector graphics. The
actual vector data isn't stored in XML syntax, but instead of a custom
syntax. This gets you a smaller file size. A parser for SVG path data is
part of Karbon core, beside other parts.
Processing PS files is more or less easy, the syntax is not so complicated.
It will become complicated if you want to implement the programming language
features of Postscript.

Yes, you can process XML files with Qt3, expat, libxml2. You can't howeer,
process the path data description as easy. I think rsvg a,d ksvg contains
their own SVG path parser. Karbons SVG Path parser is based upon the KSVG
one.

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]