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

List:       koffice-devel
Subject:    Re: PPT->KPresenter filter
From:       "\\\"shaheed r. haque\\\"" <srhaque () iee ! org>
Date:       2004-11-05 14:47:06
Message-ID: 1099666026.418b926a2fc34 () netmail ! pipex ! net
[Download RAW message or body]

Quoting Michael Goldish <michaelgol@bezeqint.net>:

> Each KPresenter slide produced by the PPT filter is a blank slide with a 
> single embedded Karbon object, which covers the entire slide. This is because
> 
> everything (shapes, colors, even texts, and probably the background too, 
> though I'm not sure about it) is described as MSOD objects inside the MSOD 
> chunk. This means that the user has to do all editing operations with Karbon,
> 
> and can't use KPresenter features, like a master slide (a planned feature 
> according to Thorsten Zachmann) and dashed lines (a feature I could find in 
> KPresenter but not in Karbon?).
> 
> Is this acceptable?
> 
> It is possible to import MSOD to KPresenter directly, without using Karbon, 
> but then KWord and KSpread won't be able to use the MSOD filter in the 
> future.

I think you should do whichever is easiest first since we will need both. For
example, MS Word generally allows drawing directly on a page as well as into a
picture. I fully expect MSOD to grow subclasses to handle the different cases -
that's why the pure virtual gotXXX() methods exist in msod.h and why all the
karbon-specific logic is in a derived class. Just make a different derived class
for the direct to kpresenter case!

And once you have something working, its much easier (for others?) to fill in
the gaps :-)

Thanks, Shaheec
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]