From koffice-devel Wed Oct 30 18:54:50 2002 From: =?utf-8?Q?Dirk_Sch=C3=B6nberger?= Date: Wed, 30 Oct 2002 18:54:50 +0000 To: koffice-devel Subject: Re: The road goes ever on X-MARC-Message: https://marc.info/?l=koffice-devel&m=103600648721686 > 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