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

List:       koffice-devel
Subject:    Re: KWord Filters not saving floating images
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-02-12 11:33:35
[Download RAW message or body]

On Wednesday 12 February 2003 09:43, Clarence Dang wrote:
> On Sat, 8 Feb 2003 03:36 am, Nicolas Goutte wrote:
> > As KMail cuts the message at "--", I cannot answer in the previous
> > message.
>
> Oops, sorry.
>
> > 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.

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?)

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

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

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

>
> > 4. Multiple spaces in HTML.
> >
> > CSS allows "white-space:pre;" but that makes the same as <pre>
>
> Is that a clean way of doing it?

No, not cleaner than <PRE>. So if you do not like <PRE>, you do not like 
"white-space:pre;" as it is the same. (So better use <PRE> to have backward 
compatibility with old HTML user agents.)

>
> > 5. Who is going to implement it?
> >
> > As written in another email, I have not any time to do non-trivial work
> > on KOffice at least until the 1st of March.
>
> I'll give it a go then but I'll have to update kdelibs/kio/kio/kservice*
> first and see if KOffice works again with HEAD.
>
> Thanks,
> Clarence

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]