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

List:       koffice-devel
Subject:    Re: KWord Filters not saving floating images
From:       Clarence Dang <dang () kde ! org>
Date:       2003-02-13 9:12:50
[Download RAW message or body]

On Wed, 12 Feb 2003 10:33 pm, Nicolas Goutte wrote:
> On Wednesday 12 February 2003 09:43, Clarence Dang wrote:
> > On Sat, 8 Feb 2003 03:36 am, Nicolas Goutte wrote:
> > > 2. Header/footer in plain text export filter
> > >
> > > I had seen the commit in kde-cvs, but I am still not sure how useful it
> > > is. I think that we have here really a different goal. You seem to
> > > prefer as loseless filter as possible, I prefer a filter that has a
> > > useful result. (The user is warned by an extra dialog that the file
> > > format is not native and therefore that the filter will lose features.)
> >
> > Hmm, but my idea is that the foreign file format should be made to store
> > as much as possible, reducing lossiness while still being useful.  To be
> > honest, I think that many people prefer to work exclusively in foreign
> > formats so it's not a matter of "I'll work on this KWord file and when I
> > need to transfer the file somewhere I'll "export it to another format"
> > but then I'll continue working on the KWord file".  It's just they will
> > probably not have a KWord file at all and so they will be quite annoyed
> > when they lose their precious formatting/headers/footers etc. (I was once
> > when I did this wonderful header/footer and saved to Plain Text in Word97
> > and lost it completely).
>
> I think that there is really a limit in this.
>
Of course but I didn't think I hit it yet :)

> You really cannot expect that another file format, especially one like
> plain text, keeps everything. That is just not possible. (You do not want
> to simulate a formula or an image in plain text, do you? And how would you
> preserve formatting?)
>
I know but it's just that not saving the header _really_ stuffed me up once.
Anyway, I've got a dialog (see my post coming in a few minutes) option now, 
defaulting this feature to off.

> > > However, as all these potential filters seems to have already a dialog,
> > > I think that we should let choose the user in the filter dialog if he
> > > wants the headers or not.
> >
> > No more dialogs please! :) unless the filter already has one as you said.
> > Yes probably that would be the best solution.  Easy so I'll implement it
> > later for ascii/plain text.  Hmm, maybe filter settings should be
> > persistant and stored in KoDocument...
>
> I had wanted to use the normal KDE config files for storing dialog values.
> However, i had never had time to implement it.
>
Would be good for storing filter settings between KWord sessions, I agree but 
I much prefer the KoDocument method:

> Using KoDocument is not good im my opinion, as mostly you have a constant
> behavior toward a filter. (For example, if you would export to a Mac, you
> would perhaps always want "Aplle Roman" encoding and "CR" end of lines.)
>
What if you work with both Windows and Linux and want to save to either LF or 
CRLF depending on the document...this is a common case...I really don't think 
the behaviour is that constant (at least for me).  And I've already written 
the code so...

> > > 3. Additional information in KWord's file.
> > >
> > > I had already thought about adding such information in the KWord file
> > > format. However, in this case, we will get a problem when we switch to
> > > an OpenOffice file format, because we will have no place to add this
> > > data.
> > >
> > > I think that here we have a conflict between simply saving the file and
> > > using the file for filters. The filters need as much information as
> > > possible (all what KoText/KWord knows would be the optimum.) However
> > > for saving a user want a file as small as possible.
> > >
> > > I think that we are hitting here the limit of file-to-file filter
> > > model. May be it is the time to think about switching to
> > > document-to-file filters for KWord.
> >
> > Hmm, suppose another word proccessor was rendering the frames and had
> > slightly different interline-spacing...it would be useful to know
> > approximately where the frame was - sort of primitive WYSIWYG hints.
>
> As OOWriter has always anchors, my problem is gone. (But with a frame
> anchored to a page in OOWriter, you will still not know near which
> paragraph it was.)
>
Well I just tested saving a document with a floating image in Word97 to .WRI 
and it saved the floating image (as inline of course since .WRI doesn't 
support floating frames) so we really can't dump then at the start if we want 
KWord to be better than Word97.

Thanks,
Clarence

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