Nicolas GOUTTE wrote:
> 
> Having a KHtml KPart would be perhaps a nice idea but it has also drawbacks
> and does *not* replace a correctly working HTML / XHTML filter for KWord.
> 

	-- snip --

> *My Point Of View*
> 
> I think the best would be to have a correctly working filter for HTML / XHTML
> to replace the current useless one (import as ASCII text, export is forgetting
> "half" of the text!)
> 
> May be KHtml can be our help, as it defines a complete HTML DOM implementation.
> Someone should look at KHtml in general and see how to use it for a KWord's filter.
> KHtml will be always up-to-date and the HTML DOM implementation should be able to
> screen us from crazy HTML web pages (I mean "crazy" in the HTML description of
> them, not how they look like on a screen!)
> 

I have complained about the non-functional html and text export filters
for some time, but until KWord has more developers these filters
probably won't be very usable.  The html export filter, at best, only
converts one line and the plain text filter didn't even write to a file
last time I tried them.  So, it's a good idea not to open an html
document you want to keep in kword and then try to export it back to the
same file name.  That will result in data loss.

I'm no longer directly involved in kword development except in how the
component I'm working on for koffice might relate to kword vis-a-vis
embedding and import/export, eventually. For example, editing a
bitmapped graphics inside kword.

Working on text and html filters would be a VERY good task for a new
koffice developer, in that it's not too complex and is very do-able with
immediate results.  The import filters also need some work.

The question is - how do we get more koffice developers willing to put
in at 10-20 hours a week until all components are up to par. In my
opinion that's pretty useless with kword because development has been
taken off into another branch to make major changes without affecting
what's publicly available in the main cvs.  Effectively removing kword
development from public access may have been necessary in this case, but
it should be a very short term thing.  This discourages new developers
from getting involved in what appears to be a closed development
process.

But since filters work directly on the document and don't really need
the application for much, they can be worked on separately.

Kword would make an excellent html editor with the filters working
properly.  Html and whatever will replace it, like xhtml, is a very
common format.  It will be some time before people start exchanging
files in .kwd format, it they ever do, so saving in html format or
docbook xml from which a doc can be converted to html would be very
useful and would do more than any one thing to increase usage and
acceptance of kword and koffice in general.
The .kwd format is of course very useful and necessary for printing and
saving work in progress and embedding components and lots more, but it
is very unlikely that the final save format will be .kwd for most
documents.

In my opinion, the last thing kword needs is an embedded khtml part or
any more complexity than it already has.  Hopefully various performance
and stability issues will be resolved in the work now being done on
kword in a special cvs branch. This work should simplify rather than add
even more complexity. 

John
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel