RE: [Embedlets-developer] Re: OpenOffice XML file

[Christopher S. <cs...@oo...>]

Just tried a couple of experiments:

Experiment #1 Version Tracking:
1. Enabled the pretty print option.
2. Extracted and committed the doc with text and graphics.
3. Added text, moved graphic and added more graphidcs.
4. Save and extract
5. Ran a diff on content.xml

The result:

1. Text changes are clearly highlighted on a line by line basis - limited by
Araxis' orientation on code diff
2. Graphics are still crammed into one line making it difficult to see the
differences. This may not be an issue as it is probable that one would
replace a drawing wholesale rather than trying to merge minute movements and
sizes etc.


Experiment #2 Document merge:

1. Committed extracted document with text and graphics.
2. Removed the graphics and some formatting
3. Diffed the results and manually merged the graphics and formatting back
into the stripped content.XML
4. Replaced the context.xml with the merged version in the .sxw file, using
WinZip.
5. Saved the file and re-opened in OpenOffice.

The Result:

1. Voila! the graphics and formatting re-appeared exactly as intended.


In order for this to work I think that we would need:

1. An automatic procedure to extract/reconstitute the documents beween the
repository tree and the .sxw (zip) format. OpenOffice does have VBA
compatible automation (hold your yuks, there is room on this planet for a
few inferior languages)

2. Possibly diff/merge tool that has fine grain diff highlighting
capability.

I did notice that I could not open a drawing file using WinZip - are the
other document types stored as xml or just the text and it's embedded
drawings?



-----Original Message-----
From: emb...@li...
[mailto:emb...@li...]On Behalf Of Ted
Kosan
Sent: Thursday, January 30, 2003 12:36 AM
To: emb...@li...
Subject: [Embedlets-developer] Re: OpenOffice XML file


Chris,

> I definitely like the xml form of the extracted documents, it
> seems that we
> have been waiting a long time for a non-proprietary document
> exchange
> format.

I am glad that you see the potential here too.  I know that there are no
guarantees that this will work but I think the potential benefits we would
receive if it does are substantial.



> I guess my general assertion would be that as long as there
> is a clean and
> relatively seamless procedure to collaboratively edit the
> documents and
> track the changes in cvs, I would encourage the group to
> settle on
> OpenOffice as the preferred document editor, with HTML based
> editors as a
> fall back.

I have stated my position on this issue but I am reluctant to move forward
unless most of us agree that this is a good idea.  How do we reach a
consensus?



> 1. The extracted content.xml has no line separators [snip]

OpenOffice comes with its file size optimizations set to 'true'.  In order
to
enable pretty printing of the XML files, go under Tools, Options, Load/Save,
General and turn size optimization off.



> Ted, would you be the one to test and document the cvs
> procedures as they
> relate to OpenOffice?

I would be happy to do this.  Before I start, though, could you please do
the
CVS experiments you did earlier with XML pretty printing turned on and then
report your findings back to the list?


Thanks,


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer