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

List:       koffice-devel
Subject:    RE: KWord status
From:       Nicolas GOUTTE <nicog () snafu ! de>
Date:       2001-02-10 21:24:21
[Download RAW message or body]



>From:	Thomas Zander [SMTP:zander@planescape.com]
>Sent:	Saturday, February 10, 2001 11:30 AM
>To:	koffice-devel@max.tat.physik.uni-tuebingen.de
>Subject:	Re: KWord status
>
>> I do not intend to make anybody angry, to offence anybody or to make
>> anybody feel personnaly attacked but I would like to say a few things 
about
>> the current situation of KWord.
>
>No problem.
>
>> It is not good that the application that many people considers the most
>> important one (or that they await the most) in the whole KDE project is 
in
>> such a uncertain state.
>
>Agreed... Well, start coding allready !! :)
>
>> 1. File formats
>> It would help if the work around KWord's core could still be continued 
in
>> the meantime. When the new KWord will be ready, most of what is needed
>> beside it would be there already. So it would save time until a stable
>> KWord exists.
>
>I recently noted this as well, development will continue in the HEAD, on
>other stuff.
>
>> To achieve that filters work with the new KWord and that new developers
>> feel welcome to KWord's world, I think that a few things are needed in
>> particularly on the level of KWord's file format:
>> - How does the new file format of KWord look likes (I am not naive 
enough
>> to think it would stay the same!)
>
>Be surprised, they will stay the same. Special commitment from the start 
;)

In the meantime, I think too that the least thing KWord needs now is a new 
file format. By the way, XHTML+CSS2 cannot help much, as they are not 
covering many parts of KWord (e.g. text columns or integrating other 
KParts).

>
>I want to pick 2 comments to make a point:
>> - Avoid tags that can represent many things at the same time. (Why is an 
>> anchor a <FORMAT> in KWord?)
>
>Because we want to create generic enough tags that allow us to easily 
expand
>on current funtionality. Meaning that it is easy to create a new version
>of kword, with different internal formatting, maybe extra funtionality, 
and
>still use the same file format.

I fear that is not that easy. The idea behind SGML, HTML, XML and others 
(including Rich Text Format) is that tags you don't know, you can leave 
them or you have a default behaviour for unknown tags and elements. But as 
filter, I know <FORMAT>! So I treat it as always. Anchors too! But... 
anchors are special! You must skip the character in the <TEXT> element 
because it is an non-printable one. And anchors have no length attributes! 
So again something special for <FORMAT>! Would a <ANCHOR> tag exists, 
saying that an anchor exists before character position twelve for example 
(and not that it *is* the character number twelve), then I can skip it 
completely if the export file format does not know what an anchor is.
The standard behaviour of XML (so therefore it should apply to KWord's file 
format) is that you skip attributes you do not know or whose values you 
cannot treat! That is not what KWord's expects from its export filters, I 
am afraid!
With every new extension of KWord's <FORMAT> tag, you would break existing 
filters!
Having discovered the anchor problem, I need now to recode the AbiWord and 
the HTML export to skip the unwanted non-printable character.
It is such a problem I have tried to describe with my question. I hope I am 
more explicit now.

>> - In one word, please think also about filter developers and don't make 
a
>> file format that is just good for (one version of) KWord!
>
>We know, and we did. (btw, thats much more then one word ;)
>
>
>> 2. External style sheets
>> Personnaly I dislike to take out the style sheet from the document. I
>> understand why HTML/XHTML does it but I do not understand why KWord 
should
>> do so.
>
>The reasoning is the following (just like with stylesheets)
>That a company can force styles to be used company wide, and individual 
workers
>can not change the formatting. This is something a _lot_ of companies 
want..
>But I recently was confinced this is more trouble then it is wourth, 
basically
>because it is a half solution..

I have thought that template files were made for this. Additionaly the 
formatting can always be changed paragraph by paragraph, character by 
character if it is forbidden to change the styles.

>What you (well all those companies anyway) really want is a way to store 
the
>info in a markup-independent style. And format it the way you want at 
publishing
>time, but thats in the far future..

I start to understand the reason. It is the same reason, why HTML in 
general prefers external style sheets.
May be there should be a tool in KWord to take style sheets from a document 
and to copy it to another. MS Word 97 has such a function where you can 
copy style sheets from the document to its template or vice-versa. For 
KWord, I suggest that such a tool should work also between two documents.

>> 3. KWord in general.
>> Many (potential) users awaits an application like the old word 
processing
>> application they have used. Care should be taken not to break this too
>> much. To give a recent example, forbiding users to have double spaces is 
a
>> bad behaviour for KWord (even if it looks odd!) (And filter developer
>> cannot do miracles. For example tabulators do not exists in HTML!)
>
>We agreed it is to be a config option. I don't understand your pointer
>to html, html does not do multiple spaces either...

Not true! <PRE> elements save all spaces. In other elements, you must 
transform all but the last space into non-breaking spaces (&nbsp;). It is 
on my to-do list for the HTML export. There is also the possibility to code 
the space as &#32; but I have never tested it, so I do not know if it is a 
real alternative.
But perhaps, you are right that HTML is not the best example.

>And my opinion is that we are trying to create a good WP, not a new WP on 
a
>non-Windows platform. So we should look closely at the mistakes made 
earlier
>and fix those.

Yes, but you are under KOffice and not an independant program. Under an 
office suite, people have preconceived ideas and this particularly concerns 
the WP programm. I thought it was due to this, including the double space 
problem, that KLyx left KOffice (but may be I am wrong!).

>As to double spaces; ask any proof reader, it is the most made mistake..

Could be "allowing multiples spaces" be a property of the layout? (Put it 
in style sheets too!)

>> 4. Depreciated Files
>> Please note in the current CVS which files are depreciated, so every
>> programmer knows that he/she should not modify anything in it, but a 
very
>> serious bug!
>> On the other side, files whitout it can be modified and the programmer
>> could be fairly certain that his/her modifications would stay, even 
after
>> the change of KWord's core!
>> Example: at the top of those files add:
>> // This file is depreciated
>
>Good point, but quite hard to accomplish.. I'll try..

If it cannot be made file by file, then please mark the most important f  
unctions that must be replaced! Or those where it is clear that they will 
be replaced.
Perhaps I was not clear enough. For me depreciated files are not necessary 
files that will be deleted but files where so much will be changed by the 
new code that it is not worth to program for the old code.

>--
>Thomas Zander 
                                           zander@earthling.net
>The only thing worse than failure is the fear of trying something new

Thank you to have answered.

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