'Re: The road goes ever on'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: The road goes ever on
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2002-10-31 7:37:59
[Download RAW message or body]

On Wednesday 30 October 2002 9:54 pm, Dirk Schönberger wrote:
|  > 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...

I think we were speaking about SVG, no?
So, if TrollTech adds support for SVG 1.1 in X11 version of QT - than they 
need to do the same in Windows and MacOS X versions.

As about WMF: they can map GDI calls to Windows GDI on Windows platform, but 
that doesn't help with X11 and Mac OS X.

I think that instead of writing N renderers (for N vector formats), it's 
better to write (N-1) converters to SVG format, and render SVG.
Note that WMF and EMF formats are developed, and we need support ofr them (on 
Linux/KDE) just for compatibility with WIndows platform (MS Word .doc files, 
may be, some clipart)

|
|  > * limited resources  (and no request for such features from customers
|  > who *pay* money for Qt)
|
|  I think this is the real reason.

Sure.  AFAIK there is only one office suite which uses Qt3.
(I am not sure about Hancom office, may be they are second - but I haven't 
seen it)
So, we are on *bleeding edge* of development. And just hitting some limits of 
existing toolkits.

Cool!

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

And this makes PDF a better candidate for parsing/data interchange, comparing 
to PS.  I think XPDF is not dependant on GhostScript, so you may want to take 
a look on its code, too.

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

And what you are going to do about emdedded fonts?
And "substituted parts" of those?

PS is not only "paths". Main purpose of PS is *fonts*.

As about embedded fonts - well, it can be done :-)
You need 
* extract font from PS file
* decode/reencode
* supply font to FreeType
* render it using FreeType, and return results back.

Are you ready for that? :-)

-- 

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] 