Showing posts with label OpenOffice. Show all posts
Showing posts with label OpenOffice. Show all posts

Sunday, 17 October 2010

Oracles OpenOffice commitment

As you might have read, Oracle is committed to OpenOffice.

As a long term follower of Oracles policy, especially its adoption of open standards, I'm pretty convinced that they will push forward OpenOffice development. First thing, Oracle made an announcement. This is definitely a good way to show commitment and support.

If OpenOffice is under the tight grip of the coroners of innovation, is there any hope for an open and free office suite?

My hope rests on LibreOffice.

Sunday, 29 March 2009

OpenOffice 3.0 with Samba file shares

With OpenOffice 3.0.1 (it has to be added using an external ppa repository from Launchpad) I could not read nor write files to and from my Samba file server. It worked under 2.4.1.

Developers on Launchpad denied to acknowledge the bug, even though it was reported widely on the internet.

The issue seems to have something to do with the way, OpenOffice authenticates with Samba. In order to get a different behaviour, one can change the way, OpenOffice is called.

If you start OOo from the menu, the call is:
ooffice -writer %U (with calc and the others following the pattern)
This tells OpenOffice, it should hand the user credentials to samba and authenticate. The result is the well documented error, the file cannot be read or written, a dialog asking for username and password for workgroup MSHOME, etc. appearing.

Under Ubuntu 8.10 you can adjust the menu setting to:
ooffice-writer %F (same with all the others)
If you have a connection to the Samba server (e.g. a share mounted), you can access the files there, both read and write.

This is a workaround for Ubuntu 8.10 (sorry for posting it so late, but I did not find out until recently).

Under Ubuntu 9.04 (bound to be out April 23, 2009) OpenOffice works with the %U parameter as well.

Tuesday, 28 October 2008

OpenOffice 3.0 on Ubuntu 8.10

OpenOffice 3.0 is not released with Ubuntu 8.10. I downloaded OOo300 (.deb) from the OpenOffice web site, unpacked them and tried to install it.

Using the update shell script did not work

Installing all .debs packages manually is possible but tedious. One also risks that aptitude or apt-get does not see the installation. Certainly, old packages are not removed. This page describes the procedure. Not recommended.

Using dpkg-scanpackages to create a Packages.gz is a possibility. However, this requires to install from a local drive which produces errors. Not nice, but works.

The Fast lane

The following procedings seems the fastes and most secure way to install OpenOffice 3.0 and maintaining the upgradability on the fly:
  1. Launch Synaptic Package Manager
  2. Select Settings/Repositories (this will start the Software Sources control panel)
  3. Add the following line to the Third party software repositories:
    deb http://ppa.launchpad.net/openoffice-pkgs/ubuntu intrepid main
  4. Close the dialog and confirm that the list of repositories will be reloaded
  5. Choose Mark All Upgrades
  6. Apply changes.
This will upgrade your OpenOffice 2.4.1 to 3.0. It will also migrate your settings (some things are reset though, like the year offsetting digit replacement).

Warning!
I have tested this on Ubuntu 8.10 32bit and it works. On 8.04.1 64bit it seems that not all programs are available as packages (e.g. Draw and Impress are missing). I turns out, this is due to missing libraries.

Sunday, 30 March 2008

Error in OpenOffice DicOOo wizard

The dictionary installation wizard of OpenOffice 2.3 is not working correctly. You can start it, start DicOOo macro and download language specific dictionaries, thesauruses and hyphenation module. However, after launching OpenOffice again, spellchecking is still missing.

What's wrong?

Apt-get installs OpenOffice with a set of language packs. If one wants to install more language packs, OpenOffice offers a wizard to install them. I need some extra language packs for my work:
de_AT
de_DE
fr_FR
There are two officially announced methods to install:
  1. Use the wizard as root will install additional dictionaries into the /usr/lib/openoffice branch of the file system (I didn't try this, so I don't know whether it works)
  2. Use the wizard as user to install into the local home directory (I tried this and it definately did not work)
If you use local installation, all files fo into ~/.openoffice/user/wordbook directory. All files get copied. A special file - dictionary.lst - contains a list of installed language packs. You can install spell checking, hyphenation and thesauruses seperately (or exclude them by editing dictionary.lst)

In Windows installations local dictionaries get installed into a directory ...dict/ooo in the local application tree. It turns out that OpenOffice looks in ~/.openoffice/user/dict/ooo for additional language packs.

A better solution

Installing something into a directory which is not maintained by the installation scripts of the distribution may backfire later. If you want to give a user a specific language pack, installing into ~/.openoffice/user/dict/ooo is the only working solution.

If you want to install language packs globally, there is a better solution: Install the myspell localized languages.
This will not only install spellchecking, hyphenation and thesaurus for OpenOffice but will provide the same functionality for Mozilla Firefox and Thunderbird.

Preferable.

Thursday, 26 April 2007

Krieg der offenen Dateiformate

ODF vs. OpenXML

In seinem Blog [1] behauptet Brian Jones, Office Program Manager bei Microsoft, dass der Krieg der offenen Dateiformate beendet sei. Grund sei die Freigabe einer speziellen Version von OpenOffice durch Novell, welche Daten in Microsofts neuem Fileformat OpenXML lesen und schreiben kann. Tatsächlich handelt es sich nur um einen eigenständigen Konverter [2], der OpenOffice Writer Dokumente in Word 2007 Dokumente umwandelt. Ist der Krieg der offenen Dateiformate tatsächlich beendet?

Bisher speicherte Anwendungssoftware ihre Daten als ein Abbild des Hauptspeichers auf Festplatten. Dieser Vorgang ist schnell und effizient, langwierige Übersetzungen der Datenstrukturen unterbleiben. Er ist aber auch fehleranfällig. Speicherabbilder enthalten Querverweise und Verkettungen. Ein fehlerhafter Wert beim Datentransfer führt zu unbrauchbaren Gesamtergebnissen.

Im Lauf der Jahre wurden die internen Datenstrukturen immer komplizierter. Anfänglich bestanden Dokumente nur aus Zeichenketten. Später kamen Textformatierungen, Schriftarten, eingelagerte Bilder und Tabellen hinzu. Mit steigender Komplexität stieg der Platzbedarf auf Datenträgern und die Dauer, welche die Software zum Einlesen und Abspeichern benötigt. Mit jeder neuen Version entstanden Unverträglichkeiten mit den Daten der Vorgängerversionen. Die Datenübernahme anderer Hersteller wurde durch fehlende oder ungenügende Dokumentation der Dateiformate behindert. Besonders der Marktführer Microsoft verteidigte seine Position vehement, sowohl durch laufende Änderung der Dateiformate, als auch durch Verbot von Rückübersetzungen. So entwickelten Alternativanbieter Import- und Exportfilter welche rudimentären Dokumentenaustausch ermöglichen. Um das ursprüngliche Erscheinungsbild wiederherzustellen sind jedoch aufwendige manuelle Nacharbeiten notwendig.

Wozu neue Dateiformate?

Längerfristig entstanden Probleme beim Zugriff, bei der Lesbarkeit, Nutzbarkeit und Vergleichbarkeit von Dokumenten. Besonders im Bereich öffentlicher Verwaltungen besteht Bedarf, auf alte und historische Dokumente uneingeschränkt zugreifen zu können. Über Jahrhunderte wurde Papier als Informationsspeicher erfolgreich genutzt. Ein Ersatz durch elektronische Datenverarbeitung kann nur dann erfolgen, wenn die Nachhaltigkeit, Vertraulichkeit, Sicherheit und Datenintegrität gewährleistet werden kann.

Mit herkömmlichen Dateiformaten sind derartige Anforderungen nicht abzudecken. Parallel zum wachsenden Bedarf aus dem öffentlichen Sektor wuchs der Kostendruck in Unternehmen, hervorgerufen durch Unverträglichkeiten bei den Dateiformaten und daraus resultierender Ineffizienz der Arbeitsabläufe.

Langzeittauglichkeit gefordert

Führende Softwarefirmen entwickelten im Rahmen des OASIS Konsortiums [3] einen offenen Dokumentenstandard, der die gravierendsten Probleme wie Langfristigkeit, Lesbarkeit und Fehlerresistenz lösen soll. Das Open Document Format (ODF) [4] versprach ein Ende bisheriger Inkompatibilitäten zwischen Dateiformaten, sowohl versions- als auch herstellerübergreifend. Mit über 700 Seiten ist der Standard umfassend und für zukünftige Erweiterungen offen.

Öffentliche Verwaltungen und Institutionen erkannten das Potential des neuen Standards. Neben einigen Bundesstaaten der USA definierten vor allem Länder aus Südamerika und Europa sowie einige asiatische Länder ODF als verbindlichen Dokumentenstandard im Parteienverkehr und der internen Abläufe. Spätestens mit der Ankündigung des Department of Defence (DoD) im Jahr 2003, verstärkt Open Source Software und offene Dokumentenstandards zu nutzen, reagierte Microsoft auf diese Entwicklungen.

Nicht nur Mittel zur Datenspeicherung

Microsoft verfügt über einen hohen Marktanteil im Bereich des Basisbetriebssystems, der Standard-Anwendungssoftware und auch bei den Dokumentenformaten. Insbesondere die Dokumentenformate helfen Microsoft, Updatezyklen bei der Standardsoftware und den Betriebssystemen massgeblich zu steuern. Unverträglichkeiten zwischen den Versionen führen mittelfristig dazu, dass Firmen über ihre Aussenkontakte zu einem Update gezwungen sind, wenn sie nicht den elektronischen Anschluss an ihre Partner verpassen wollen. Automatisierte Systemnachbesserungen erleichtern es Microsoft, diesen Zwang nach belieben zu verstärken. Eine nachhaltige Neuorientierung grosser Kunden wie dem DoD gefährdet die Marktposition von Microsoft in Ihren Grundfesten.

Diese Abkehr war nur durch die Bereitstellung offener Standards im Bereich der Dateiformate zu verhindern. ODF als Dateiformat kommt aus marktpolitischen Überlegungen für Microsoft nicht in Frage. So wurde 2005 im Rahmen der ECMA ein neuer Standard ausgearbeitet: ECMA-376 oder Office OpenXML [5,6] wurde am 7. Dezember 2006 trotz zahlreicher technischer Einsprüche [7] durchgesetzt. Dieser Standard umfasst derzeit mehr als 6.500 Seiten, zahlreiche XML Schemaspezifikationen und deckt die Office-Anwendungen Word, Excel, Powerpoint und Access ab [8,9].

(Ironie am Rande: In seiner Proposalpräsentation vor der ECMA [10] verweist Brian Jones auf ein Dokument der EU zum Thema Open Document Standards und Vorteile der Nutzung. Das Originaldokument [11] beschreibt allerdings diese Vorteile unter eindeutigem Bezug auf ODF)

Was können die neuen Formate ...

ODF und OpenXML sind technisch sehr ähnlich. Sie speichern verschiedene Bestandteile der Dokumente als XML Dateien in ZIP Archiv ab. ZIP ist ein anerkannter und weit verbreiteter Kompressionsalgorithmus. XML ist eine erweiterbare Beschreibungssprache für hierarchisch gliederbare Datenbestände. XML Dateien sind zwar grösser als binäre Dateiformate gleichen Inhalts, lassen sich aber aufgrund der hohen Informationsredundanz besser komprimieren. Die komprimierten Archive können schneller auf Datenträger geschrieben und von dort gelesen werden. Dateiinhalte werden nicht unmittelbar in den Arbeitsspeicher übernommen, sondern zuerst analysiert und in maschinenverwertbare Form umgewandelt. Die Dateiformate sind fehlerresistenter als Ihre Vorgänger. Beide Dateiformate können aufgrund ihrer offenen Struktur automatisiert nachbearbeitet werden.

ODF und OpenXML erlauben die Einbindung binärer Informationsfragmente sowie Script- und Makrosprachen. Das führt zu neuen Sicherheitsrisiken. Keines der beiden Formate bietet hinreichenden integrierten Schutz vor ungewollten Änderungen von Dateninhalten. Sie bieten genügend Angriffsfläche zum Einschleusen von Schadcode. Es bleibt den Anwendungsprogrammen überlassen, dies zu verhindern. Microsoft Office prüft anhand der Erweiterung des Dateinamens, ob der Aufruf von Makros erlaubt ist. Dieser Schutz ist allerdings leicht zu umgehen und suggeriert daher eine nicht vorhandene Sicherheit.

Beide Formate gewährleisten den längerfristigen Zugriff auf Daten. In der Darstellung hängen Sie - wie ihre traditionellen Vorgänger - von zahlreichen externen Faktoren ab. Das optisch gleiche Erscheinungsbild kann mit den aktuellen Standards nicht garantiert werden.

... und wo unterscheiden sie sich?

ODF Dateien sind kleiner als ihr OpenXML Pendant. ODF speichert Inhalte gemeinsam mit der Formatierung. OpenXML trennt konsequent Text von der Formatierung. Das ist technisch sauberer und führt erstaunlicherweise nicht zu längeren Ladezeiten. Microsoft behält sich die Option vor, grössere Dateien auch in einem proprietären Format einzubinden, um eventuelle Engpässe in der Performance zu umgehen. Hier sind Inkompatibilitäten vorprogrammiert.

OpenXML greift nicht auf bestehende Standards zurück. Unter anderem wurden neue Standards für Grafiken, Texten, Tabellen, mathematischen Formel, Länder- und Farbcodes definiert. Damit wurde die Spezifikation aufgebläht. In der Umsetzung erhöht das die Fehleranfälligkeit von Anwendungssoftware und Formatkonvertern. ODF setzt in allen Bereichen auf etablierte Standards wie SVG, XML, mathML und standardisierte ISO-Codes.

Wie frei ist „Frei“?

ODF und OpenXML sind lizensierbare Standards, deren Nutzung unentgeltlich ist. ODF kann im Rahmen der Lizenzen durch Dritte ergänzt werden. Das Open Document White Paper verweist auf 9 Referenzimplementation [12]. Zu einigen davon ist der Quellcode verfügbar. Dem gegenüber verweist Microsoft nur auf eine Referenzimplementation, Office 2007, welche nicht quelloffen ist.

Ein Gutachten bestätigt ODF patentrechtliche Unbedenklichkeit. Sun, Hauptzulieferer zum ODF-Standard, hat einen ergänzenden Forderungsverzicht abgegeben. Der Ausstieg einzelner Mitglieder aus dem OASIS Konsortium ist klar geregelt, sodass in Zukunft Ansprüche von Altmitgliedern nicht zu erwarten sind. Eventuell zukünftig auftauchende Forderungen aus Patentrechten werden nicht vollständig ausgeschlossen. OASIS bestätigt dieses marginale Restrisiko, sieht aber selbst keinen Lösungsansatz.

Microsoft stellt die Nutzung von OpenXML jedermann frei. Microsoft verweist auf seine Patente im OpenXML Standard, gibt allerdings auch einen schriftlichen Klagsverzicht auf seiner Website ab. Dieser erschöpft sich auf die im Standard berührten Technologien und Patente. Patente, die von der ordnungsgemässen Umsetzung der OpenXML-Spezifikation in Anwendungssoftware berührt werden, sowie eventuelle Patente von Drittherstellern sind von dieser Freistellung nicht betroffen. Insbesondere bei der Einbindung in Anwendungssoftware sehen Rechtsexperten ein nicht unbeträchtliches Rechtsrisiko welches Microsoft nicht entkräftet.

Sowohl ODF als auch OpenXML sind derzeit sowohl frei zugänglich, frei nutzbar, frei von Kosten sowie frei von patentrechtlichen Einschränkungen. ODF ist für Softwareentwickler leichter zugänglich. Der überschaubare Umfang der Spezifikationen erlaubt wirtschaftliches Einarbeiten in das Thema. OpenXML mit über 6.500 Seiten und zahlreichen Schematas drängt sich dagegen dem Interessenten nicht unmittelbar auf.

Attraktiv für den öffentlichen Bereich

Öffentliche Verwaltungen und Regierungen fordern die Nutzung offener Dateiformate aus zwei Hauptgründen:
1. soll die langfristige Nutzbarkeit auch auf unterschiedlichsten EDV-Systemen gewährleistet sein. Diese Forderung wird hauptsächlich in Ämtern und Behörden gestellt.
2. soll die starke Abhängigkeit von Softwareanbietern reduziert und - wenn möglich - lokales Know-how genutzt werden. Diese Forderung stellen vornehmlich Regierungen.

Hier hat ODF einen deutlichen Vorsprung. Das Format existiert bereits seit längerer Zeit, ist einige Male implementiert und in quelloffener Form zugänglich. Der Standard wird sowohl von einigen grossen Softwareherstellern als auch von einer umfangreichen Entwicklergemeinschaft unterstützt. ODF hat noch einige Einschränkungen, die den Einsatz im öffentlichen Bereich behindern. Die langfristige Erweiterbarkeit ist noch nicht nachgewiesen. OpenXML kann auf keine substantiellen Vorteile verweisen, welche einen Einsatz zwingend notwendig machen würden. Allerdings besitzt Microsoft eine breite installierte Basis, auf die das Unternehmen starken Einfluss über seine automatisierten Updates ausüben kann.

Öffentliche Stellen können bis zu einer endgültigen Lösung der offenen Probleme die ersten Schritte in Richtung Automatisierung gehen. Notwendige Ergänzungen lassen sich in weiteren Phasen der Umsetzung nachziehen.

Attraktiv für Unternehmen?

Unternehmen agieren in kurzfristigeren Innovationszyklen. Nur ein geringer Teil der betriebsnotwendigen Informationen haben langfristige Relevanz (Verträge, Finanzinformationen) und müssen entsprechend archiviert und gewartet werden. Der Rest der Arbeitsdokumente hat eine geringe Halbwertszeit.

Eine grundsätzliche Entscheidung bezüglich eines Dateiformates ist nur dann möglich, wenn die Entscheidung bezüglich alternativer Anwendungssoftware zur Disposition steht. Das Erstellen von ODF Dateien mit Microsoft Office (Word, Excel, Powerpoint, Access) ist heute nicht möglich und zukünftig nicht absehbar. Umgekehrt ist das Erstellen von OpenXML Dateien aus alternativer Anwendungssoftware derzeit nur eingeschränkt möglich. Da Microsofts Anwendungsprogramme in Unternehmen besonders stark verbreitet sind, ist der Einsatz von OpenXML zumindest dort vorhersehbar.

Bekannte Migrationsprojekte, wie jenes der Stadt München oder der Lufthansa, sind weitgehend von strategischen, politischen oder ideellen Motiven geleitet. Wirtschaftliche Vorteile bei der Betrachtung der Gesamtkosten sind marginal oder nicht vorhanden. Wer sich letztlich durchsetzen wird - öffentliche Verwaltungen und Regierungen die ODF bevorzugen oder Unternehmen die Microsoft mit OpenXML nutzen - ist derzeit nicht prognostizierbar.

Der Krieg der offenen Dateiformate ist demnach noch nicht beendet. Wir erleben bestenfalls eine kurzfristigen Waffenstillstand.


Bibliographie:
[1] Blog Brian Jones
[2] Novell OpenXML Translator
[3] OASIS Gründungsmitglieder
[4] Open Document for Office Applications
[5] ECMA-376 - Office OpenXML
[6] Office OpenXML Fact Sheet
[7] Objections to JTC-1 Fast-Track Processing of the Ecma 376 Specification v. 0.1, 27.1.2007
[8] ECMA-376 OpenXML White Paper
[9] Introducing the Office (2007) Open XML File Formats
[10] Start of TC45: Presentation to GA
[11] TAC approval on conclusions and recommendations on open document formats
[12] Open by Design, ODF White Paper