[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-06 5:54:32
[Download RAW message or body]

On Wed, 5 Feb 2003 12:12 am, Nicolas Goutte wrote:
> On Tuesday 04 February 2003 11:44, Clarence Dang wrote:
> > On Tue, 4 Feb 2003 06:34 am, Nicolas Goutte wrote:
> > > Yes, libexport can only handle anchored pictures, therefore only
> > > inlined pictures.
> > >
> > > Dumping things at the end is not welcomed by the users.
> >
> > Yes but it's better than not having them at all.
>
> I do not know.
>
> It seems to me that missing items means for user "ooh, this feature is not
> supported" 
Yes but then that user makes some negative comments about KWord and/or its 
filters, to say the least.  I really think that a "bug" is better than not 
exporting at all (it would be fatal if you depend on KWord filters for school 
assignments for instance).

> while items at the end means more "this is a bug."
Yes, but I am not so much interested as to what the export filter should do 
but rather what libexport should do - at least tell the export filters about 
doFloatingFrame()...it is up to the filter to decide what to do with it.

> > > It is already criticized with text frames.
> >
> > Hmm, what's wrong with the way text frames are handled?  I like how text
> > frames are being exported at the moment.  Ok, admittedly it won't be
> > pretty for DTP mode...
>
> Well, people adding frames (be it text or image frames) want them exported
> in the way KWord display them. Mostly people do not understand that frames
> cannot be exported. 
This would depend on the format, wouldn't it?

> They do especially not understand it if the file format
> seems to have something similar (like boxes in CSS.)
>
> You could also look at my discussions (on both koffice mailing lists) with
> Vadim about exporting text frames to HTML/CSS. (Sorry, I have not the uRLs
> at hand and I have not the time to search.) 
Yes, it's very difficult with HTML - that is why you are doing that filter and 
not me :)  BTW, it is possible to make HTML preserve spaces without a <pre> 
hack?

> > > I do not understand what you want to do with th eframe coordinates, as
> > > I do not know any format that can do something with absolute
> > > coordinates if the data is given at the end.
> >
> > Flowing text around floating frames.
>
> I would really be interested on how you would make it work. 
I'm not actually interested in making floating frames work - just letting the 
export filters know about them.  Then I might figure out what I want to do 
with the frames.  I mean the idea is that we give libexport full 
functionality and it really is then up to the filter e.g. suppose we were 
exporting to a format that supported floating frames and flowing text etc. - 
this extra information would be very useful compared to none at all.

> Personally, I
> have tried with HTML/CSS and it has never worked. (KWord has absolute
> coordinates, while, for floating, CSS needs relative coordinates.
> Additionally the text frame must be in the middle of the text where it will
> be used and not at the end.)
>

Thanks,
Clarence
>
> > > On Monday 03 February 2003 10:46, Clarence Dang wrote:
> > > > Hi,
> > > >
> > > > If I try to save to a format that supports pictures (e.g. rtf, html,
> > > > wri), the non-inlined pictures in the document are not saved.  This
> > > > is a serious problem because a user would simply not expect that
> > > > toggling the "inlineness" of a picture would result in it not being
> > > > saved.
> > > >
> > > > It appears to be a problem with libexport because it won't save
> > > > framesets that don't have an anchor in the text pointing to them.
> > > > Maybe dump out all the framesets at the end that haven't yet been
> > > > saved earlier (with frame coordinates)?
> >


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