headers
Tomas Mecir | 1 Nov 2004 14:12
Picon

Re: koffice/kspread

Well, I'm not 100% sure about filters, but formatting code shouldn't
be affected by this. I've been working with that part quite closely in
the last days, and I'm kinda confident that everything will be okay
(of course, I'll be testing stuff more).
I'll also have a look at the filters, but I don't expect any problems
there. These may need to be adjusted to support the general format
though - at least for import/export formats that support this feature
- this includes every other spreadsheet application that I know of ;)

On Sun, 31 Oct 2004 18:20:58 +0100, Laurent Montel <montel <at> kde.org> wrote:
> On Sunday 31 October 2004 17:54, Tomas Mecir wrote:
> > CVS commit by mecir:
> >
> > Added the General format to the list of cell formats. It's not supported
> > yet though...
> 
> Are you sure that this commit doesn't break all kspread format or kspread
> import/export filter ?
> 
> Regards.
> 
> >
> >   M +2 -1      kspread_global.h   1.29
> >
> >
> > --- koffice/kspread/kspread_global.h  #1.28:1.29
> >  <at>  <at>  -70,5 +70,6  <at>  <at>  enum MethodOfCalc { SumOfNumber, Min, Ma
> >
> >  enum FormatType {
> > -    Number_format=0, Text_format=5, Money_format=10, Percentage_format=25,
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Faure | 1 Nov 2004 17:24
Picon
Favicon
Gravatar

Re: [patch] Color button behavior in KWord, KPresenter, KSpread, Kivio

On Saturday 30 October 2004 16:33, Sven Langkamp wrote:
> Hi,
> I have now implemented the behaviour suggested in 52001 for the text, line and 
> fill toolbar buttons in KWord, KPresenter, KSpread and Kivio. Comments?

OK.

--

-- 
David Faure, faure <at> kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
Permalink | Reply | 0 comments |
headers
Michael Goldish | 1 Nov 2004 20:16

Re: MSOD and PPT import filters

Hi,

I ran into some trouble with the MSOD->Karbon filter and I need some advice:

1. MSOD doesn't only have host specific data - it also requires some 
information from the host. For example, the texts of each powerpoint slide 
are stored outside the MSOD chunk, but are referenced from within it. The 
same goes for the color scheme as far as I know.
Therefore, I think host specific information needs to be passed to the 
MSOD->Karbon filter. Is it a good idea to prepend host specific data to the 
MSOD data sent to the filter? It can be packed like an ordinary MSOD 
container, with an atom identifying the host (maybe an integer that will 
equal 0 for powerpoint, 1 for ms word and 2 for excel?), and then a sub 
container with host records (in the host's format) that are relevant to the 
MSOD filter (for powerpoint these are text and color scheme records). If the 
filter can't find the host specific container it will attempt to function 
without host specific information, so it remains compatible with programs 
already using it (currently only the PPT filter). Even though this method will 
work, I'm not sure it's the right way to go, so please help me out a little.

2. If I understand correctly, Karbon describes (in its XML files) text 
characters (and strings) like it does shapes. This means I need to specify 
the character shape data myself. I could do this by making a list of 
character shapes (which I can generate with Karbon) to be scaled/rotated as 
necessary to construct strings. However, I can only do this for a limited 
number of fonts (one?). Is this an acceptable solution?

Thanks.

On Wednesday 27 October 2004 19:14, Werner Trobin wrote:
(Continue reading)

Permalink | Reply | 12 comments |
headers
Nicolas Goutte | 1 Nov 2004 19:10
Picon

New Junior Jobs (kofficecore and KWord/KPresenter)

I have a list of new junior jobs to do. (Putting them in KDE Bugs would take 
more time.)

1. Replacing ::unlink by QFile::remove
In koffice/lib/kofficecore/koDocument.cc line 1301, there is a call 
to ::unlink this should be replaced to QFile::remove (of course then calling 
QFile::encodeName is not needed anymore)
(See also if one of the #includes can be removed. I am not sure abou that.)

2. Use KoStoreDevice in KoDocument::savePreview
In koffice/lib/kofficecore/koDocument.cc line 1200, the thumbnail is saved 
used QBuffer. It should use KoStoreDevice instead, like in SaveOasisPreview 
(line 1181)

3. Network transparency when saving pictures.
In KWord (koffice/kword/kwview.cc line 5913)
and KPresenter (koffice/kpresenter/kpresenter_view.cc line 745), the saving of 
the picture is done without network transparency.
KIO::NetAccess::upload should be used (with a KTempFile) if the file is not 
local.

Have a nice day!
Permalink | Reply | 12 comments |
headers
Nicolas Goutte | 1 Nov 2004 19:22
Picon

Re: MSOD and PPT import filters

On Monday 01 November 2004 20:16, Michael Goldish wrote:
> Hi,
>
> I ran into some trouble with the MSOD->Karbon filter and I need some
> advice:
>
> 1. MSOD doesn't only have host specific data - it also requires some
> information from the host. For example, the texts of each powerpoint slide
> are stored outside the MSOD chunk, but are referenced from within it. The
> same goes for the color scheme as far as I know.
> Therefore, I think host specific information needs to be passed to the
> MSOD->Karbon filter. Is it a good idea to prepend host specific data to the
> MSOD data sent to the filter? It can be packed like an ordinary MSOD
> container, with an atom identifying the host (maybe an integer that will
> equal 0 for powerpoint, 1 for ms word and 2 for excel?), and then a sub
> container with host records (in the host's format) that are relevant to the
> MSOD filter (for powerpoint these are text and color scheme records). If
> the filter can't find the host specific container it will attempt to
> function without host specific information, so it remains compatible with
> programs already using it (currently only the PPT filter). Even though this
> method will work, I'm not sure it's the right way to go, so please help me
> out a little.

As Werner has told, create an enum or so and set it currently to PowerPoint. 
After we will have made all changes to the filter system to support OASIS 
(and perhaps to fix other problems), we could try to implement such things 
(like what is the format of the parent file.)

The current problem is that not any developer has time to change/improve the 
filter system. (There is even a patch from Clarence Dang pending since many
(Continue reading)

Permalink | Reply | 11 comments |
headers
Nicolas Goutte | 1 Nov 2004 19:38
Picon

Re: MSOD and PPT import filters

On Monday 01 November 2004 19:22, Nicolas Goutte wrote:
> On Monday 01 November 2004 20:16, Michael Goldish wrote:
> > Hi,
> >
> > I ran into some trouble with the MSOD->Karbon filter and I need some
> > advice:
(...)
>
> > 2. If I understand correctly, Karbon describes (in its XML files) text
> > characters (and strings) like it does shapes. This means I need to
> > specify the character shape data myself. I could do this by making a list
> > of character shapes (which I can generate with Karbon) to be
> > scaled/rotated as necessary to construct strings. However, I can only do
> > this for a limited number of fonts (one?). Is this an acceptable
> > solution?
>
> Has SVG text written directly or indirectly as shapes?
>
> If SVG has it directly, then you could try to concentrate on writing a MSOD
> to SVG filter. Then only the SVG filter would need to be intelligent enough
> (or perhaps not at all depending on Karbon's OASIS format but that is a
> part of the OASIS specification that I do not know.)

What I mean is: this is just an idea. Perhaps there would be more people ready 
to help for SVG (for example by the developers of KSVG). Also Qt4 is supposed 
to get better SVG support too, so you would not be limited by what Karbon 
knows or not.

>
> > Thanks.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shaheed | 1 Nov 2004 22:59

Re: MSOD and PPT import filters


> What I mean is: this is just an idea. Perhaps there would be more people
> ready to help for SVG (for example by the developers of KSVG). Also Qt4 is
> supposed to get better SVG support too, so you would not be limited by what
> Karbon knows or not.

I think this is an excellent idea. I believe SVG is a reasonable match for 
MSOD.
Permalink | Reply | 0 comments |
headers
Michael Goldish | 1 Nov 2004 22:23

Re: MSOD and PPT import filters

On Monday 01 November 2004 18:22, Nicolas Goutte wrote:
> As Werner has told, create an enum or so and set it currently to
> PowerPoint. After we will have made all changes to the filter system to
> support OASIS (and perhaps to fix other problems), we could try to
> implement such things (like what is the format of the parent file.)

Even if I can assume the parent file format is powerpoint, I still need data 
from it, like the color scheme and texts. This data is stored in the PPT file 
outside the MSOD chunk, which means that normally it's not passed to the MSOD 
filter. How should I pass it? There's also an option of returning data back 
from the MSOD filter to the PPT filter (data like locations of text boxes), 
and letting the PPT filter do the main work. In any case something needs to 
be done. Or have I misunderstood you? Please forgive me if I'm confusing 
things - I'm a beginner.

> Has SVG text written directly or indirectly as shapes?
>
> If SVG has it directly, then you could try to concentrate on writing a MSOD
> to SVG filter. Then only the SVG filter would need to be intelligent enough
> (or perhaps not at all depending on Karbon's OASIS format but that is a
> part of the OASIS specification that I do not know.)

I've tried opening a SVG file that contains some text (generated by Inkscape) 
with Karbon and it appeared blank. I guess this means there's no text support 
yet? Does this mean I should start working on text support for SVG->Karbon?
Permalink | Reply | 8 comments |
headers
Rob Buis | 2 Nov 2004 09:31
Picon
Picon
Favicon

Re: MSOD and PPT import filters

Hi,

On Mon, Nov 01, 2004 at 09:23:22PM +0000, Michael Goldish wrote:
> > Has SVG text written directly or indirectly as shapes?
> >
> > If SVG has it directly, then you could try to concentrate on writing a MSOD
> > to SVG filter. Then only the SVG filter would need to be intelligent enough
> > (or perhaps not at all depending on Karbon's OASIS format but that is a
> > part of the OASIS specification that I do not know.)
> 
> I've tried opening a SVG file that contains some text (generated by Inkscape) 
> with Karbon and it appeared blank. I guess this means there's no text support 
> yet? Does this mean I should start working on text support for SVG->Karbon?

There is some code in the karbon svg import that handles text, but it is 
commented out, you could try reenabling that and see what happens, I 
forgot why it is commented out in the first place... Keep in mind the text 
handling will probably change in karbon in the future, as it is not 
optimal right now...
Cheers,

Rob.
Permalink | Reply | 0 comments |
headers
Nicolas Goutte | 2 Nov 2004 10:26
Picon

Re: MSOD and PPT import filters

On Monday 01 November 2004 22:23, Michael Goldish wrote:
> On Monday 01 November 2004 18:22, Nicolas Goutte wrote:
> > As Werner has told, create an enum or so and set it currently to
> > PowerPoint. After we will have made all changes to the filter system to
> > support OASIS (and perhaps to fix other problems), we could try to
> > implement such things (like what is the format of the parent file.)
>
> Even if I can assume the parent file format is powerpoint, I still need
> data from it, like the color scheme and texts. This data is stored in the
> PPT file outside the MSOD chunk, which means that normally it's not passed
> to the MSOD filter. How should I pass it? There's also an option of
> returning data back from the MSOD filter to the PPT filter (data like
> locations of text boxes), and letting the PPT filter do the main work. In
> any case something needs to be done. Or have I misunderstood you? Please
> forgive me if I'm confusing things - I'm a beginner.

H'm that is bad indeed.

So perhaps that means that the MSOD filter should be changed.

I do not know if there are MSOD files alone (I do not think so), so perhaps 
you would need to integrate this filter more with the current OLE filters. 
(But on the other hand the MS Word filter is not anymore with the other OLE 
filters.)

I do not know if my idea with SVG is good, but that could be a way too to 
solve the problem: to have code outside the filter system to handle MSOD to 
SVG and when you have the SVG data, you can pass it to Karbon with the 
current filter system (assuming it is needed.)
(Continue reading)

Permalink | Reply | 6 comments |

Gmane