Uploaded IRC log 2008/8/29

Please find the log of todays meeting here:

http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Minutes/2008_08#2008.2F08.2F29

Regards,
Svante

--

-- 
Sun Microsystems GmbH           Svante Schubert
Nagelsweg 55                    Software Engineer
20097 Hamburg                   StarOffice / OpenOffice.org Development
Germany                         Phone: +49(0)40 236 46 500
http://www.sun.com              Svante.Schubert@...

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Re: feature sets

Hi Michael,

On 29.08.08 05:58, m_ivanic@... wrote:
> 
> Just wanting to know if the odftoolkit had support for the following features. Had a look through the API
docs but may have missed it. If not are there tasks in the bug-tracking system to implement them ?
> 
> 1. Inserting another odf (or other format even) at any point in the document ? In such a way that preserves
section/pagesetup info, such as orientation/columns/margins. I don't mean as an embedded object of
course, but the content to be imported.
> 
> 2. replacing the result of a find with another document. Something like:
>    document.Replace(regularExpressionA, remoteDocument)
> or:
> document.Replace(searchString, caseSensitive, remoteDocument)
> 
> This sort of thing is very useful for automated document generation. Definitely nicer than manually
searching and doing the insert.
> 
> 3. Mail merging from datasets/tables etc:  
> 
> document.MailMerge(System.Data.DataTable)
> or even
> document.MailMerge(remoteDocument)

thank you for your feedback. No, these features have not been 
implemented yet. Are you interested in working on these issues? I guess 
at least 1. and 2. shouldn't be too hard to solve.

Best regards,

odt

Dear Sirs,
I am an italian student in computer science.
I am trying to develop a system using Java, that can read and visualize
documents in ODT format.
This is for personal use (i need to do this project for a course).
I would like to have Java libraries for conversion HTML from/to ODT. And any
other resource You think can be usefull for my case.
Where can i find that?

Thanks in advance for your help and time.
Kind regards,
Francesco Costanzo

odf4j Checkout Problem

Hi all

I am trying to checkout 'odf4j' using my OoO userid/password on NetBeans 6

CVS Root: :pserver:amitksaha@...:/cvs
Password :*********

However, on every attempt I get a "cannot connect to.." error.

Can anyone help?

Regards,
Amit
--

-- 
Amit Kumar Saha
*NetBeans Community Docs
Contribution Coordinator*
me blogs@ http://amitksaha.blogspot.com
URL:http://amitsaha.in.googlepages.com

R: [odftk-dev] R: [odftk-dev] PRB: AODL uses a lot of memory when working on BIG tables

Hi Darius, 
You'll find all files I patched in my email with subject "PATCH: AODL is
slow when working on BIG tables".

As regards memory consumption issues I'm still waiting to know from project
admins how should I proceed.
(fork or not fork)

Bye,
Lino

-----Messaggio originale-----
Da: Darius Damalakas [mailto:darius.damalakas@...] 
Inviato: giovedì 19 luglio 2007 13.48
A: Lino Barreca
Oggetto: Re: [odftk-dev] R: [odftk-dev] PRB: AODL uses a lot of memory when
working on BIG tables

Hi, Lino,
> Personally..
> I need to workaround this (and I'll) regardless if it becomes the
"standard"
> AODL code or just a fork from the main cvs.

> But if I can help someone with my patches then I'll do (like I did since I
> began) and I offer my patches to the public it's up to "you" decide to use
> them or not. :)
> 

Is it possible that you share your current working copy?

R: [odftk-dev] AODL is slow when working on BIG tables

What kind of events would you like to record?

Internal events? (something like "Namespace looked-up", "Node added"..)
(similar to a "Trace" log, useful for debugging)

Or public method calls? ("Cell inserted", "Added Row"..)
(I can't think what you could do with this and why this function should be
implemented in the library and not in the user code)

Let us know,
Lino

-----Messaggio originale-----
Da: Tom Schindl [mailto:listom@...] 
Inviato: lunedì 16 luglio 2007 9.43
A: dev@...
Oggetto: Re: [odftk-dev] AODL is slow when working on BIG tables

Hi,

Why not giving the user a possibility to put the system into recording 
mode (recording events and delivering a summary afterwards)?

Table#setNotificationMode(Constants.EVENT_RECORDING);
Table#addRow();
Table#addRow();
..
Table#setNotificationMode(Constants.EVENT_NORMAL); ==> kicks off a 
summary event

AODL is slow when working on BIG tables

Actually, each time I add a cell to a row an event is fired (OnRowChanged)
that is used to check/rezize all rows already added to the table.

The resize is correct but the moment is wrong (it should be done ONE TIME
ONLY when I add the row to the table.rowcollection)
This could make sense if the row is already added to a table but is a
non-sense if my row is still "detached".

If my table has 100 columns and 10000 rows this way of work is good for the
first 1000 rows, after the operation becomes very slow..
Each cell added to the row makes the validation of the whole table!!!!
Moreover this is actually done using slow methods:
Row.GetRowIndex loops on RowCollection

With the patch attached it is a bit faster (using IndexOf)
(even if I didn't changed the way/moment the whole table is resized)

If someone approves the change (when to do the check) I can modify the
sources as well.

Let me know.

Bye,
Lino

/*************************************************************************
 *
 *  OpenOffice.org - a multi-platform office productivity suite
 *

Patch for issue 79482

Hi everyone.
I'm new to this list.

I work for a big italian software company and I'm using AODL within a
project of ours.
I have to use it and so I can help the whole community to have a better
product (if I can fix/enhance something, why should I keep it for me only?
:) )

Here's the first fix.
I hope someone out there can check-in it.

(I can explain in detail why I did those changes if someone asks for it but
it was mainly for bug-fixing, as you can see yourself)

Bye,
Lino.

cvs diff -wb -i -- Table.cs
Index: Table.cs
===================================================================
RCS file: /cvs/odftoolkit/aodl/AODL/Document/Content/Tables/Table.cs,v
retrieving revision 1.3
diff -w -b -i -r1.3 Table.cs
210,211c210,211
< 		/// Inserts the cell at the specified position. Both indexes
are zero
< 		/// based indexes!
---
> 		/// Inserts the cell at the specified position. 

R: [odftk-dev] R: [odftk-dev] Re: R: [odftk-dev] Hints for AODL

Hi Oleg,
I can't help you actually because I'm doing major changes to cell.cs :D (in
addition to the little changes I did in the cell.cs you already have)
1) strongly typed values (boxed to object) so the user will not have to
convert the value to/from string before saving/reading the value
2) automatic-recognizing/setting of "office-value" and "office-valuetype"
3) handling of null/DBNull values (#N/A) (date and boolean values support
was already added in the cell.cs I gave you before)
This is more .net and developer friendly :)

Just an information:
I suppose we would not do any "breaking" interface-changes beetween the code
in the cvs version and the code released as "stable"
(If an user uses AODL 1.2 then his code should still work with AODL 1.3)

The question:
Should I use ObsoleteAttribute to mark the older methods so the code will
still work
or I can break the interface (and drop OfficeValue and OfficeValueType
properties)
signaling them in a "breaking changes section"?

Moreover..
Some member names, as I said before, should really be changed (ie.
Table.RowCollections -> Table.Rows)
So this does mean that the interface should be necessarily changed (but the
change is worth the work)
How should we proceed?

Please let me know.

R: [odftk-dev] Re: R: [odftk-dev] Hints for AODL

OK guys
So..
Here's the first patch (more to come)

This is a very important fix because without it the performace are badly
affected
(I have a lot of identical styles and this consumes a lot of memory and
processing cycles)

You'll find attached cell.cs and two sample files (one made before changes
on the style handling and one after)
The patch I did for CellStyle should be applied to every other <oblect>Style
(to make the things work as they should)
I'll work on that but I actually prefer to ehnance other pieces of code.

Let me know what do you think about that.

Attached you'll find also Table.cs and Row.cs this files have some minor
fixes (you can analyze them yourself).

BTW:
Is there a reason why the StyleName property exist?
Why can't you simply use <object>.Style.Name?

Possible answers:

1) Because setting the StyleName property handles the XML modifications
needed to persist the info
My answer: this can be easily done even with getter-setter for the style
object.