LibreOffice 26.8 und Interoperabilität: Bewahren, was noch nicht gelesen werden kann

Übersetzung: englisches Original von Italo Vignoli

LibreOffice 26.8 fügt eine grundlegende Unterstützung für den Import und Export verschiedener Diagrammtypen hinzu, die Microsoft Office in OOXML-Dateien verwendet: Box-Plot (Kastengrafik), Trichter-, Pareto-, Radial-, Treemap- und Wasserfalldiagramme. LibreOffice kann diese Diagramme zwar nicht anzeigen oder bearbeiten, erkennt sie jedoch, weist den Benutzer darauf hin, dass der Diagrammtyp noch nicht unterstützt wird, behält die zugrundeliegende Definition unverändert bei und schreibt sie beim Speichern der Datei wieder heraus.

Auf den ersten Blick mag dies wie das Eingeständnis einer Unvollständigkeit erscheinen; tatsächlich ist es jedoch ein Beispiel dafür, was die Implementierung eines proprietären Formats mit dem Ziel der Interoperabilität mit sich bringt – zum Wohle der Nutzer und nicht im Sinne einer kommerziellen Strategie, die Nutzer lediglich als Werkzeuge betrachtet.

Was ist passiert?

Microsoft hat diese Diagrammtypen ab der Version Office 2016 eingeführt und sie in einem Namensraum abgelegt, der gemeinhin als „chartex“ bezeichnet wird. Dieser Namensraum ist nicht Bestandteil des als internationaler Standard verabschiedeten ISO/IEC-29500-Textes, sondern wird separat in der Erweiterungsdokumentation von Microsoft beschrieben.

Dies ist vollkommen rechtmäßig und entspricht einer ganz normalen geschäftlichen Praxis: Ein Anbieter verbessert sein Produkt, und das Dateiformat entwickelt sich entsprechend weiter. Die Folge ist jedoch, dass das im Alltag verwendete Format nicht mehr jenem entspricht, das ursprünglich standardisiert wurde. Zwar wird in Ausschreibungsunterlagen und Richtlinien weiterhin auf die ISO-Norm verwiesen, doch die tatsächlich ausgetauschten Dateien unterscheiden sich davon.

Für jeden Implementierer außer dem Anbieter selbst führt dies zu einem dauerhaften Rückstand. Es handelt sich dabei nicht um eine einmalige Lücke, die sich mit entsprechendem Aufwand schließen ließe, sondern um einen strukturellen Rückstand: Die Spezifikationen liegen in der Hand eines Anbieters, der seinen Veröffentlichungszeitplan nicht offenlegt und dessen Prioritäten nach wirtschaftlichen Kriterien festgelegt werden.

Drei mögliche Reaktionen

Ein Office-Paket, das auf ein Diagramm stößt, das es nicht erkennt, hat drei Möglichkeiten:

  1. Das Programm kann die Datei ablehnen. Dies ist zwar eine ehrliche, aber wenig hilfreiche Lösung: Der Benutzer steht vor einem Dokument, das er nicht öffnen kann, und gelangt zu der Schlussfolgerung, dass die Software nicht funktioniert.
  2. Es kann verwerfen, was es nicht versteht. Die Datei lässt sich zwar öffnen, doch das Diagramm verschwindet; der Benutzer bemerkt dies erst, wenn das Dokument an einen Kollegen weitergeleitet wird und das Diagramm fehlt. Dies ist das problematischste Szenario, da der Verlust unbemerkt bleibt und die Schuld der Person zugeschrieben wird, die die Datei zuletzt geöffnet hat.
  3. Es kann beibehalten, was es nicht darstellen kann. Der Benutzer erhält den Hinweis, dass dieser Diagrammtyp nicht unterstützt wird, und sieht anstelle einer leeren Stelle einen Platzhalter; die zugrundeliegende Definition bleibt bei der Übertragung des Dokuments zwischen verschiedenen Anwendungen erhalten. Wird das Dokument in der ursprünglichen Anwendung wieder geöffnet, ist es vollständig wiederhergestellt.

LibreOffice 26.8 setzt auf die dritte Option – die einzige der drei, die der Tatsache Rechnung trägt, dass das Dokument dem Nutzer gehört und nicht der Software oder gar dem Unternehmen, das die Software entwickelt.

Leider gibt es dabei eine Einschränkung, die eine Ausnahme darstellt: Diagramme mit regionalen Karten enthalten umfangreiche geografische Informationen, die LibreOffice nicht beibehalten kann. Zwar übersteht der Diagrammtyp den Import-Export-Zyklus, doch bleibt nur ein Bruchteil des Inhalts unverändert erhalten.

Warum dies über die Charts hinaus wichtig ist

Der Fall Chartex ist von begrenzter Tragweite. Das zugrundeliegende Modell hingegen nicht.

Alle Organisationen, deren Dokumente in einem von einem einzigen Anbieter kontrollierten Format verfasst sind, begeben sich in eine Abhängigkeit, die sie nicht steuern können; denn die Spezifikationen können sich jederzeit und ohne Vorankündigung ändern – etwa durch das Hinzufügen von Funktionen, die nur von einer einzigen Implementierung unterstützt werden.

Es muss nichts Außergewöhnliches geschehen, damit die Archive einer Organisation für andere Software zunehmend schwerer lesbar werden.

Das Open Document Format ist nicht vor Veränderungen gefeit, doch diese vollziehen sich auf andere Weise. Überarbeitungen werden von einem technischen Ausschuss bei OASIS – dessen Arbeit öffentlich einsehbar ist – vorgeschlagen, diskutiert und verabschiedet; anschließend werden sie als Versionsspezifikationen veröffentlicht, die jeder frei implementieren kann.

Wer ODF 1.4 unterstützen möchte, kann die entsprechende Spezifikation lesen und sie in die Praxis umsetzen. Dies ist der einzige Unterschied, und er ist völlig ausreichend.

Die bidirektionale Bewahrung nicht unterstützter Funktionen zeichnet eine verantwortungsvolle Implementierung unter den gegebenen Bedingungen aus, stellt jedoch keine Verbesserung dieser Bedingungen an sich dar. LibreOffice ist die einzige Office-Suite, die diesen Ansatz verfolgt, um die Nutzer und die Inhalte ihrer Dokumente zu schützen.

Written by:

411 Posts

View All Posts
Follow Me :