Normalizing Office Documents - Revision history

Sallain at 22:00, 11 February 2020

2020-02-11T22:00:40Z

Joseph at 22:51, 1 February 2011

2011-02-01T22:51:30Z

Joseph at 22:51, 24 January 2011

2011-01-24T22:51:55Z

Joseph: Created page with 'Category:Development documentation This is a developement page, not to be confused with the Media type preservation plans.
The typical open source approach to tran...'

2011-01-24T22:35:49Z

Created page with 'Category:Development documentation This is a developement page, not to be confused with the Media type preservation plans. The typical open source approach to tran...'

New page

[[Category:Development documentation]]

This is a developement page, not to be confused with the [[Media type preservation plans]].

 The typical open source approach to transcoding MS Office documents of various formats is to use unoconv to interface with Open Office. Unfortunately, our experiences with unoconv and our system have not been as desirable as we had hoped.

 In Archivematica 0.6 we faced a problem where on boot, the first one or two conversions would fail, due to the server not being initialised. We got around that by creating a daemon to start a unoconv listener.

 In Archivematica 0.6.2, with stricter error checking, and the implementation of the MCP we came across further problems with unoconv. It would appear to hang while processing, and occasionally report errors, like 139 segmentation fault.
After much testing and we replaced unoconv with some alternative scripts we found online. [http://code.google.com/p/archivematica/issues/detail?id=304 Issue 304] was used to track this problem: . After unoconv was replaced, the occasional segmentation fault would still appear.

 We are aware that MS Office has the ability to [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f1fc413c-6d89-4f15-991b-63b07ba5f2e5&displaylang=en save] documents into pdf format, which may be able to be scripted/automated. Our concern is that this doesn't keep with the archivematica goal of being a completely open source utility. Future revisions of Archivematica may provide the option to normalize in this manner, but we would like to provide an open source alternative.

← Older revision		Revision as of 22:00, 11 February 2020
Line 1:		Line 1:
	[[Category:Development documentation]]		[[Category:Development documentation]]
		+
		+	<div style="padding: 10px 10px; border: 1px solid black; background-color: #F79086;">This page is no longer being maintained and may contain inaccurate information. Please see the [https://www.archivematica.org/docs/latest/ Archivematica documentation] for up-to-date information. </div> <p>

	This is a developement page, not to be confused with the [[Media type preservation plans]].		This is a developement page, not to be confused with the [[Media type preservation plans]].

← Older revision		Revision as of 22:51, 1 February 2011
Line 11:		Line 11:

	<br/>We are aware that MS Office has the ability to [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f1fc413c-6d89-4f15-991b-63b07ba5f2e5&displaylang=en save] documents into pdf format, which may be able to be scripted/automated. Our concern is that this doesn't keep with the archivematica goal of being a completely open source utility. Future revisions of Archivematica may provide the option to normalize in this manner, but we would like to provide an open source alternative.		<br/>We are aware that MS Office has the ability to [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f1fc413c-6d89-4f15-991b-63b07ba5f2e5&displaylang=en save] documents into pdf format, which may be able to be scripted/automated. Our concern is that this doesn't keep with the archivematica goal of being a completely open source utility. Future revisions of Archivematica may provide the option to normalize in this manner, but we would like to provide an open source alternative.
		+
		+
		+	==Notes On Replacement==
		+	Source: http://www.oooninja.com/2008/02/batch-command-line-file-conversion-with.html
		+	<br/>In archivematica: http://code.google.com/p/archivematica/source/browse/trunk/src/MCPClient/runArchivematicaMCPClient.sh#
		+	<br/>Called by: user, as part of starting client
		+
		+	Source: http://www.artofsolving.com/files/DocumentConverter.py
		+	<br/>In archivematica: http://code.google.com/p/archivematica/source/browse/trunk/src/transcoder/lib/transcoderScripts/DocumentConverter.py
		+	<br/>Called by: http://code.google.com/p/archivematica/source/browse/trunk/src/transcoder/lib/transcoderScripts/unoconvAlternativeSupport.sh

@@ Line 3: / Line 3: @@
 This is a developement page, not to be confused with the [[Media type preservation plans]].
-<br/>The typical open source approach to transcoding MS Office documents of various formats is to use unoconv to interface with Open Office. Unfortunately, our experiences with unoconv and our system have not been as desirable as we had hoped.
+<br/>The typical open source approach to transcoding MS Office documents of various formats is to use unoconv to interface with Open Office. Unfortunately, our experiences with unoconv and our system have not been great.
 <br/>In Archivematica 0.6 we faced a problem where on boot, the first one or two conversions would fail, due to the server not being initialised. We got around that by creating a daemon to start a unoconv listener.
 <br/>In Archivematica 0.6.2, with stricter error checking, and the implementation of the MCP we came across further problems with unoconv. It would appear to hang while processing, and occasionally report errors, like 139 segmentation fault.
-After much testing and we replaced unoconv with some alternative scripts we found online. [http://code.google.com/p/archivematica/issues/detail?id=304 Issue 304] was used to track this problem: . After unoconv was replaced, the occasional segmentation fault would still appear.
+After much testing and we replaced unoconv with some alternative scripts we found online. [http://code.google.com/p/archivematica/issues/detail?id=304 Issue 304] was used to track this problem: . After unoconv was replaced, the occasional segmentation fault would still appear. I believe the segmentation fault problem is in Open Office: it may be collisions of temporary files/memory between returns and cleanups, but I'm only guessing. The problem seems less frequent when longer sleeps between calls are implemented.
 <br/>We are aware that MS Office has the ability to [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f1fc413c-6d89-4f15-991b-63b07ba5f2e5&displaylang=en save] documents into pdf format, which may be able to be scripted/automated. Our concern is that this doesn't keep with the archivematica goal of being a completely open source utility. Future revisions of Archivematica may provide the option to normalize in this manner, but we would like to provide an open source alternative.

Normalizing Office Documents - Revision history

Sallain at 22:00, 11 February 2020

Joseph at 22:51, 1 February 2011

Joseph at 22:51, 24 January 2011

Joseph: Created page with 'Category:Development documentation This is a developement page, not to be confused with the Media type preservation plans. The typical open source approach to tran...'

Joseph: Created page with 'Category:Development documentation This is a developement page, not to be confused with the Media type preservation plans.
The typical open source approach to tran...'