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

List:       koffice-devel
Subject:    Re: Plans for the port of KPresenter to the new QRT stuff
From:       Vadim Plessky <lucy-ples () mtu-net ! ru>
Date:       2001-07-03 8:38:59
[Download RAW message or body]

On Monday 02 July 2001 15:54, David Faure wrote:
|   On Monday 02 July 2001 22:36, Vadim Plessky wrote:
|   > On Monday 02 July 2001 12:52, David Faure wrote:
|   > well, I still sticked to idea of web-konstructor, and it of course will
|   > need QTextEditor (WYSIWIG).
|
|   Not if it uses khtml (as kafka tries to do).

Approach used by Kafka developers is interesting, and very promising, but I 
believe there is a room for *more than one web editor* (constructor)

Kword (even in its current beta state) is doing quite good job of web 
authoring. Not everybody needs Flash animations or tons of JavaScript.
My test shown that HTML generated by KWord is easily read (and rendered 
correctly) by MS IE, Netscape 6/Mozilla and even Word 2000. Most important it 
that Cyrillic characters are not lost (like it happens when exporting from 
Macromedia Freehand, for example) and formatting info is translated correctly 
(Adobe InDesign 1.5 exports Cyrillic, but converts font sizes to pixels, 
assuming 1px=1pt as far as I see)
So, in some respect KWord is already better than Adobe or Macromedia 
offerings ;-))
 
I, personally, like a lot approach of Quark Xpress or just *good old* Xerox 
Ventura Publisher.
I refer to Ventura as "Xerox Ventura Publisher", because I used version 2.0 
of it in early 90-s, and I think it had all features 99% of people would want.
Hell, it was working on 286 processor, and pretty fast, as it was using GEM 
(from Digital Research) instead of MS Windows. :-)

Basic idea:
* you create document (frame-based, word processor-like, spreadsheet, 
whatever...)
* you *publish* it on media your want / like.
Classic usage is when you print it on printer, or create PDF from it.
Another - publish to web. (that's approach which Quark claimed as top 
priority for them in the future).
But, if electronic paper emerges in the future, you can think of "e-printing 
on e-paper" approach, which probably will have it specific requirements 
(bandwidth, update frequency, low res images, font AA, format conversions, 
etc.)

Basic framework is already here (KWord, etc.)
As about document format - I think pure XML with *all* features of CSS2 (plus 
SVG, etc., and DOM mappings in document for navigation) is _enough_.

For example, concerning David's question about "paragraph background" color.
In CSS, you have Padding and Margin for each CSS block. Margin is outside 
block, padding is inside.
Therefor, "padded" area has block's background, "margin" are - doesn't.
I think there is no need to reinvent the wheel. CSS has (almost) all fetures 
you need for good document formatting.
I think that it's easier to have both "padding" and "margins" in Kword than 
trying to implement full-screen WYSIWYG formatting in Kafka.
Or I am wrong here?

// what CSS lacks is common reference implementation. MS IE really sucks 
here, Mozilla was failing on rather trivial things until recent release, 0.9.1
And I doubt Mozilla will become widely used.
Konq/khtml has very good CSS implementation, while still lacks support for 
some elements. Longterm, KOffice of course has advantage over MS Office, as 
their [microsoft's] CSS implementation is not as good as in KDE.
Shortterm, MS has bigger installed base and can tweak standards  :-((
-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
Do you have Arial font installed? Just test it!
http://kde2.newmail.ru/font_test_arial.html
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

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