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

List:       koffice-devel
Subject:    Re: New RTF export filter for KWord
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-11-02 14:56:49
[Download RAW message or body]

On Saturday 02 November 2002 14:10, Ariya Hidayat wrote:
> > The function ProcessUnderlineTag, which reads the <UNDERLINE> tag, is in
> > the file koffice/filters/kword/libexport/ProcessDocument.cc, line 218
>
> Thanks for the information. It's done already (also applied to import
> filter). Theoritically, "advanced underline" is fully supported now.

Just a little problem at import: you have defined \ulw two times in the big 
table. I suppose that the second one should be for wave.

> In addition, since KWord underline is more advanced than RTF spec, is it
> possible to embedded some information which will be discarded by other RTF
> reader (e.g MS Word) but still be recognized again by KWord ? This way,
> things like "double underline, word by word, in red" might be converted to
> simple double underline in RTF but additional info is kept so when KWord
> reads the document again, it will be back to original underline
> (double+word+red). Is it allowed ? And is it good thing ?

In theory, it should work. The potential problem of any extension is that a 
RTF reader might choke at it. (It has to better not be any version of MS 
Word.)

Especially the main keyword must be standard or a header may skip the text.

So something like (assuming that color 2 is red):
{\uld \kwordunderlinewordbyword \kwordunderlinecolor2 This is the text}
might work.

You will have also to find out if you have to write \* before your private 
keywords or not. I have never really understood when tto use it (except when 
you define a "direction".)

>
> > You can look in the file koffice/filters/kword/abiword/abiwordexport.cc.
> > There is a method AbiWordWorker::convertUnknownImage which converts
> > images into PNG (as AbiWord support only PNG.) The code only works if you
> > know that QImage support the image format. (However, you can try to load
> > the picture and if it does not work, you will know that you cannot
> > convert it.)
>
> This is exactly the right place. I'll grab relevant code from here and will
> put it in RTF exporter. Somehow it could also be in libexport.
> Also, maybe it's important to provide original size of the image. When the
> document is read in MS Word, scaling still will be possible then.

Well, if you have to convert the image, you can use QImage::size. Otherwise, 
load the picture in a KoPicture (for example with KoPicture::load) and use 
KoPIcture::getOriginalSize

>
> > As for converting cliparts into WMF (or into MSOD), well that is another
> > problem. Perhaps it is something to coordinate with anybody who would
> > want to do a native MS Word export filter.
>
> Another choice would be RTF DrawingObject (\do). But that's also a great
> amount of work (and another pages for me to consume).

If you would want to do this, you should look at Kontour's RTF export filter.
However the other problem is how much supported are these drawing objects in 
RTF readers,

>
>

Have a nice day/evening/night!

> _______________________________________________
> koffice-devel mailing list
> koffice-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/koffice-devel

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