headers
Korinek Pavol | 1 Mar 2010 09:49
Favicon

RE: captions

Yes it is in kofficetests  folder.

http://websvn.kde.org/trunk/tests/kofficetests/interoperability/kword/oowriter/oow_cap_roman_numbers.odt?view=log

-- 
Mani

-----Original Message-----
From: Thorsten Zachmann [mailto:t.zachmann <at> zagge.de] 
Sent: Saturday, February 27, 2010 6:58 AM
To: For developer's discussion about KOffice
Subject: Re: captions

Hello,

On Thursday 25 February 2010 14:52:50 Korinek Pavol wrote:
> Hello,
> 
> I have some results of investigation of bug
> https://projects.maemo.org/bugzilla/show_bug.cgi?id=150283  and I like to
> consult it with you guys if I'm right.
> 
This page only gives a login screen for which I and also other koffice 
developers don't have access to. Is it possible for you that you send the file 
in question so that everybody can have a look at it? Or is the file available 
in the test documents which where added recently?

Thorsten
_______________________________________________
koffice-devel mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jos van den Oever | 1 Mar 2010 12:04
Favicon

Re: Review Request: Enable the modification of KoXml DOM tree

On Saturday 27 February 2010 07:16:40 Ganesh Paramasivam wrote:
> > On 2010-02-27 04:56:52, Thorsten Zachmann wrote:
> > > Can you please explain why you need to modify the document while you
> > > are loading it?
> > > 
> > > Please note that modifying is not possible as the document is const
> > > during loading.
> > > 
> > > I personally think that modifying of the document during the loading
> > > should be avoided.
> 
> This is due to the approach taken by ODF spec for storing delete changes.
> Deleted changes in a document are stored separately in a <text:deletion>
> tag and a <change change-id=""> is placed at the location of deletion. ODF
> specifies the following rules to the used for loading delete changes
> 
> To reconstruct the text before a deletion took place:
> -If the change mark is inside a paragraph, insert the text content of the
> <text:deletion> element as if the beginning <text:p> and final </text:p>
> tags were missing. -If the change mark is inside a heading, proceed as
> above, except adapt the end tags to match their new counterparts.
> -Otherwise, copy the text content of the <text:deletion> element in place
> of the change mark.
> 
> As you can see, these rules actually imply a modification of the DOM. We
> already have a working code for loading delete changes which does not
> require a write-able DOM tree. But the code would be a lot more cleaner
> with a write-able one. Hence this change.

Could you achieve the same functionality by using a local copy of the affected
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dag Andersen | 1 Mar 2010 09:47
Picon

Re: koreports dependencies (was koffice)

Lørdag 27 februar 2010 17:20:05 skrev Thomas Zander:
> On Saturday 27. February 2010 14.02.43 Cyrille Berger wrote:
> > On Friday 26 February 2010, Adam Pigg wrote:
> > > SVN commit 1096573 by piggz:
> > >
> > > Move koreport to /libs (used by kexi and kplato)
> > > Fix kexi and kplato builds
> >
> > and breaks build when kchart is disabled. The dependency between koreport
> >  and other modules (especially applications) needs to be removed.
> 
> Talked a bit with Adam on IRC and he asked me to write an email with a
>  summary In base; libraries (in koffice/libs) can not depend on stuff
>  outside of the libs.
> 
> 
> * the CMakeFile.txt has a -DHAVE_KWORD which luckily seems to be unused.
>  But should be removed.
> * The KoReportKSpreadRenderer class depends on the kspreadcommon library in
> order to allow reports to be written to ods.
> This should be changed to get rid of the dependency. I think the ods
>  fileformat is pretty simple and maybe just using libkoodf and
>  QXmlStreamWriter would do the trick.
> * It depends on kdchart. Which means it turned into GPL and the libs in
> koffice/libs should all be LGPL. It also can't depend on it because kdchart
>  is outside of kofficelibs.
> On IRC I suggested to move the classes that depend on kdchart for
>  KOffice2.2 somewhere else and come up with a better solution for 2.3 or
>  later.
IMVHO putting koreport libs somewhere separate (like koffice/reportlibs) for
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thomas Zander | 1 Mar 2010 10:02
Picon
Favicon

Re: Move to git on March, 4th

On Thursday 4. February 2010 15.57.49 Cyrille Berger wrote:
> In serveral threads we have mentioned the date for a move to git. Last 
> suggestion is to do it on March 4th, one day after the hard freeze for
>  KOffice  2.2 (and between 2.1.2 and 2.2 Beta1 releases).

I'm wondering what the progress is, how is the communication with the board 
going? How is the communication with the sysadmin team going about having 
serverspace for the initial download?
What will we do with the koffice dir in svn while and after the transfer?
Should we send out a reminder email to more than KOffice-devel ?

Also what do people think about the blog post send here; 
http://aseigo.blogspot.com/2010/02/keeping-it-our-source-code-together.html

Seems the board has not yet reached an agreement with gitorious. Which leaves 
the future of koffice-on-gitorious a bit uncertain right now.

Question, questions :)
--

-- 
Thomas Zander
Permalink | Reply | 10 comments |
headers
Ganesh Paramasivam | 1 Mar 2010 15:17

Re: Review Request: Enable the modification of KoXml DOM tree

> Could you achieve the same functionality by using a local copy of the affected
> nodes or a dom wrapper?

I was thinking along this lines, but any of these solutions would
defeat one of my prime motivations which was to leverage on the
existing KoTextLoader code without having to change it.

Anyway, since the general response to this patch has been to leave the
DOM as read-only ( with valid reasons ), I have decided not to proceed
down this path for now ( As I said, this was just a clean-up, we
already have a working code ).

Thanks,
Ganesh
Permalink | Reply | 0 comments |
headers
Jaroslaw S | 1 Mar 2010 17:22
Picon

Re: koreports dependencies (was koffice)

On 1 March 2010 09:47, Dag Andersen <danders <at> get2net.dk> wrote:
> KoReportKSpreadRenderer is a sort of export function similar to
> KoReportHTMLCSSRenderer thst exports to a file.

It's not hard to imagine a case when the output goes directly to a
WebKit view without touching filesystem.

> Maybe KoReportKSpreadRenderer should also export to file and thus remove the
> kspread dependency.

Good for unit tests.
But then how to display the data in already running kspread instance?
(I do not mention lowered efficiency)

> As I see it, *all* the report entities (label, text, image...) could be
> replaced with shapes, they solve (parts of) the same problem.

Yes, they display in a similar way but only that. They are
saved/loaded in a different way (we have hardcoded odf saving for now,
e.g. no way to save directly to a non-odf format, we're using filter
chains).

> I side effect of this would be that it would be very easy to export to odf.

True, although exporting to odf is a rarely used case, since editing
happens on source data, on on reports directly.

> But I think this discussion should be postponed, and be part of a discussion
> on how to (if at all) integrate reports in koffice in general.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Thomas Zander | 1 Mar 2010 17:37
Picon
Favicon

Re: koreports dependencies (was koffice)

On Monday 1. March 2010 17.22.25 Jaroslaw S wrote:
> > Maybe KoReportKSpreadRenderer should also export to file and thus remove
> > the kspread dependency.
> 
> Good for unit tests.
> But then how to display the data in already running kspread instance?

The flake component system makes components out of apps and allows you to show 
a spreadsheet table in any flake supporting application. Populating it from the 
ODF source (can be from a QByteArray) to show the real data.
So this is easy to do using flake. Its in essence what its designed to do :)

--

-- 
Thomas Zander
Permalink | Reply | 4 comments |
headers
piggz1@gmail.com | 1 Mar 2010 17:41
Picon

RE: koreports dependencies (was koffice)

Sorry for top posting, hitting reply on my phone doesnt indent the original text.

Atm, the kspread renderer only goes to a file anyway, it doesnt open kspread.  The correct behaviour should
be to save the file, and open it with whatever the user has chosen, be it oo or kspread. Libkspreadcommon,
was only used for the easy file generation, so as i said, i will look to changing this.

I agree that report generation is typically one way,with the odd occasion where editing is needed.  This is
the reason for the kspread/html exporters (msa can also export to rtf, but im unsure how that will work atm,
but it is a goal to get it into a wordprocessor).

I also see how entities are like shapes..but mainly in the designer, and i think there mabe needs to be a new
type of data aware shape.

For the most part, i thin most use cases/workflows are covered....i base this on the fact i do a lot of reports
in my day job, though there is always room for improvement :)
---
Adam Pigg
Sent from my Nokia E71
-----Original Message-----
From: Jaroslaw S
Sent:  01/03/2010 16:22:25
Subject:  Re: koreports dependencies (was koffice)

On 1 March 2010 09:47, Dag Andersen <danders <at> get2net.dk> wrote:
> KoReportKSpreadRenderer is a sort of export function similar to
> KoReportHTMLCSSRenderer thst exports to a file.

It's not hard to imagine a case when the output goes directly to a
WebKit view without touching filesystem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jaroslaw S | 1 Mar 2010 17:49
Picon

Re: koreports dependencies (was koffice)

On 1 March 2010 17:37, Thomas Zander <zander <at> kde.org> wrote:
> On Monday 1. March 2010 17.22.25 Jaroslaw S wrote:
>> > Maybe KoReportKSpreadRenderer should also export to file and thus remove
>> > the kspread dependency.
>>
>> Good for unit tests.
>> But then how to display the data in already running kspread instance?
>
> The flake component system makes components out of apps and allows you to show
> a spreadsheet table in any flake supporting application. Populating it from the
> ODF source (can be from a QByteArray) to show the real data.
> So this is easy to do using flake. Its in essence what its designed to do :)

This is the point where we do nto understand each other, and that
started quite long ago ;) We don't need to display just a whole
document (or sheet in a workbook - this is very special case) but we
want to pysh/pull a tabular data and share it between apps. Ideally
with limited/removed copying. The data is so often unstored, as comes
from a query or external migration data source).

This does not mean flake is incompatible. This only means we'll
probably incrementally extend the feature set.

--

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
 KDE Software Development Platform on MS Windows (http://windows.kde.org)
Permalink | Reply | 3 comments |
headers
Thomas Zander | 1 Mar 2010 18:26
Picon
Favicon

Re: koreports dependencies (was koffice)

On Monday 1. March 2010 17.49.12 Jaroslaw S wrote:
> On 1 March 2010 17:37, Thomas Zander <zander <at> kde.org> wrote:
> > On Monday 1. March 2010 17.22.25 Jaroslaw S wrote:
> >> > Maybe KoReportKSpreadRenderer should also export to file and thus
> >> > remove the kspread dependency.
> >>
> >> Good for unit tests.
> >> But then how to display the data in already running kspread instance?
> >
> > The flake component system makes components out of apps and allows you to
> > show a spreadsheet table in any flake supporting application. Populating
> > it from the ODF source (can be from a QByteArray) to show the real data.
> > So this is easy to do using flake. Its in essence what its designed to do
> > :)
> 
> This is the point where we do nto understand each other, and that
> started quite long ago ;) We don't need to display just a whole
> document (or sheet in a workbook - this is very special case) but we
> want to pysh/pull a tabular data and share it between apps. Ideally
> with limited/removed copying.

I guess we just changed topic away from KoReports to something else. Adam gave 
a nice overview of spreadsheet support and how to solve it, which sounds like 
a great solution to me and avoids the deeper questions you pose for now.

--

-- 
Thomas Zander
Permalink | Reply | 0 comments |

Gmane