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

List:       koffice-devel
Subject:    Re: New RTF export filter for KWord
From:       Ariya Hidayat <ariya () kde ! org>
Date:       2002-11-03 9:48:48
[Download RAW message or body]


> 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.
Oops, thanks for telling. It's fixed now.

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

According to latest RTF 1.5 spec, any RTF reader must implement \* control 
word, which could be the key to implement such thing.

I found that thing like this:
\uld{\*\kword{\color2\word}}
works without problem in MS Word (they're just ignored).

This is indeed opens the possibility of using RTF as "lossless" KWord document 
format, up to certain extent. Of course, the question is whether this is a 
good thing or not. In fact, it's likely the case with HTML as "lossless" MS 
Word document format: some users might like it (they don't care about 
addition of HTML bloatness and other MS-invented style-sheet), while the 
others just complained loud.

> 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

I get this using QImage since I need dpi information for \picwgoal and 
\pichgoal. Further more, \picscalex and \picscaley can be easily inferred 
from frame size. However \picw and \pich really confuse me. According to the 
spec, it should be "picture width in pixels" and "picture height in pixels". 
My experiment with MS Word showed that \picw always equals to 1.77 times 
\picwgoal (same with \pich), regardless the picture's size and resolution. Am 
I missing something ?

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

Hmm, this is indeed a valid point. Reading the spec again, looks like it's 
there because of Word95/Word97 support. So it may or may not be recognized by 
any other application

BTW, a quick check with Valgrind revealed many "Use of uninitialised value" in 
libexport, especially in ProcessFormatTag, SubProcessFormatOneTag, and  
CreateMissingFormatData. I'll see what I can do.

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