Nachfolgend die Beschreibung einiger Nicklichkeiten, die mir heute an produktiven Arbeitsplätzen auffielen, bei denen gerade von Openoffice 2.4 auf Openoffice 3.0.1 bzw. 3.1.0.6 gewechselt worden war:

Impress 3.0.1 und Einzüge der Gliederungspunkte

Hatte man sich im Master einer OO 2.4 odp-Datei die Bullets und die Einzüge der verschiedenen Gliederungsebenen mühsam über die Formatierung der “Nummerierung und Aufzählungszeichen” hingebastelt, so freut man sich natürlich, wenn man das Dokument unter OO 3.0.1 öffnet und die Gliederungspunkte seiner Präsentationsseiten an den alten Stellen vorfindet. Die Freude wird jedoch schlagartig getrübt, wenn man dann in einer solchen Liste von Gliederungspunkten einen neuen Punkt einfügen will, ihn mit der Tab-Taste auf die richtige Ebene bringt und der neue Punkt plötzlich nach rechts oder links verschoben auftaucht, während alle alten Punkte auf der Zielebene da verharren, wo sie waren.

Als Ursache entpuppt sich nach ein wenig Spielerei eine Korrektur des Berechnungsverfahrens für die Einzüge in Kombination mit evtl. Einzugsvorgaben in den Formatvorlagen für die Gliederungsebenen “Gliederung 1, Gleiderung 2, … ” : Hatte man in OO 2.4 in der Formatbeschreibung der “Gliederung x” einen Einzug definiert und gleichzeitig eine Positionierung der Bullets und Texte über die “Nummerierung” vorgenommen, so zog der durch die “Nummerierung” vorgegebene Einzug. Der Einzug der Formatvorlage “Gliederung x” blieb unwirksam.

In OO 3 wird dagegen der Gesamteinzug (richtigerweise) so berechnet, dass der Absatzeinzug zunächst über die Vorgabe für die “Gliederung x” vorgegeben wird. Additiv hinzu kommt dann der über die Nummerierungsformatierung definierte Einzug. Hatte man also im OO 2.4 odp-Dokument Einzüge für die Gliederungs-Formatvorlagen definiert, so werden diese Einzüge für neu angelegte Gliederungspunkte unter OO 3.0.1 plötzlich wirksam. Das Peinliche an der Sache ist das, dass man es sich bei der Übernahme der 2.4 Objekte zu einfach gemacht hat: Dort bleibt nämlich zunächst alles beim alten. Nur jeder neu (!) angelegte Gliederungspunkt verrutscht. Für den Anwender ist dies zunächst ein völlig undurchschaubares Verhalten.

Das Ganze funktioniert nach dem Muster: Wir haben die Berechnung der Einzüge verändert. Damit die Anwender beim Öffnen von Dokumenten aus früheren OO-Versionen nicht gleich erschrecken, lassen wir die Positionierung der alten Gliederungspunkte trotz neuer Berechnungsvorschrift unverändert. Die neue Positionsberechnung wenden wir nur auf neue Punkte an.

Dies ist ein Beispiel dafür, wie man durch Behebung eines Fehlers und gleichzeitige inkonsequente Übertragung der Berechnungsvorschriften auf alte Dokumente-Einträge den unbedarften Anwender vorübergehend in den Wahnsinn treiben kann.

Um die aus dem 2.4-er-Stand übernommen Gliederungspunkte mit den neuen Gliederungspunkten bzgl. des Einzugs gleichzuschalten, kann man übrigens die Einzugsdefinitionen für die Formatvorlagen “Gliederung x” in einem betroffenen Dokument komplett auf 0 stellen.

Impress 3.x und die Position von Tabulatoren

Hat man das Lineal eingeblendet und fügt einem Gliederungsabsatz einen Tabulator hinzu und schiebt diesen dann im Linealbereich per Maus auf die Position 22.0 cm, so würde man als naiver Anwender erwarten, dass ein Öffnen der Maske zum Editieren der Tabulatoreigenschaften des Absatzes einem dann eine Position von “22.0 cm” anzeigt. Dies ist jedoch nicht der Fall: Je nach Einzugsdefinition der Formatvorlage “Gliederung x” wird ein anderer Wert angezeigt. Nur die Addition des Absatzeinzugs mit der Tabulatorposition ergibt die graphisch vorgegebene Wunschposition 22.0 cm. Die Tabulatorposition ist also relativ zum Einzug zu verstehen.

Wäre man umgekehrt von vornherein über die Eingabemaske für Tabuatoreigenschaften vorgegangen und hätte dort die Tabulatorposition auf 22.0cm vorgegeben, so hätte man sich gewundert, warum der Tabulator im graphischen Lineal nicht bei 22.0 cm steht. Hier vermisse ich einen kleinen entsprechenden Hinweis für den User in der Maske zur Tabulatorpflege.

Ausbleibender Screenupdate beim Löschen eingefügter Zeilen mit Formeln in Calc 3.0.1

Man füge 2 Zeilen in ein OO 3.0.1 ods-Tabellendokument ein – mit folgenden Eigenschaften:
Zeile 1: Spalte A: Beliebiger Text / Spalte C: Zahlenwert 50 / Spalte D: Zahlenwert 1 / Spalte F : Funktion WENN(D1=1;C1;0)
Zeile 2: Spalte A: Beliebiger Text / Spalte C: Zahlenwert 80 / Spalte D: Zahlenwert 0 / Spalte F : Funktion WENN(D2=1;C2;0)

Nun füge man eine leere Zeile zwischen diesen beiden Zeilen ein. Im nächsten Schritt versuche man, die eben eingefügte Zeile zu löschen (per Kontextmenü). Auf dem PC, auf dem ich heute gearbeitet habe, verschwand dann das Kontextmenü nur teilweise und die zu löschende Zeile blieb stehen. Erst ein über andere Aktionen erzwungener Screenupdate (z.B. durch ein kurzes Scrollen mit der Maus) führte zum gewünschten Ergebnis in der Tabellenansicht. Wehe dem User, der den Screenupdate nicht erzwingt und in die verbleibene (optisch) nicht gelöschte Zeile etwas reinschreibt. Beim nächsten Screenupdate verschwindet dann die gelöschte Zeile doch und die Änderung hat sich leider 1 Zeile tiefer ausgewirkt.

Das Problem taucht nicht auf, wenn man keine Formeln in den Zellen der Zeile hat. Naiv würde ich mal vermuten, dass die Ursache eines solchen Bugs darin liegt, dass man in einem Modell-View-Kontext vergessen hat, nach dem Updaten aller Formelergebnisse im Modell-Bereich auch den View wieder upzudaten.

Der Fehler taucht in aktuelleren Versionen von Calc nicht mehr auf. Dennoch war er in der produktiven Umgebung , in der ich heute arbeiten musste, fast ein Show-Stopper.

Probleme beim Öffnen von doc-Dokumenten in OO 3.1.0.6, die mit Writer 2.4 erzeugt wurden

Meine Frau und ich müssen ab und zu mit doc-Dokumenten umgehen oder solche ausliefern. Das machen wir natürlich – soweit möglich – mit OO. Blöd nur, wenn man ein Dokument mit wichtigen Tabellen, das man mit Writer 2.4 erzeugt und ins “doc”-Format umgewandelt hatte, nun mit Writer 3.1.0.6 öffnet und die Tabellen nicht mehr sieht. Noch blöder, wenn die Tabellen Basisdaten für eine Rechnung enthalten haben und der Kunde bestimmte Rechnungspositionen gerade jetzt am Telefon diskutieren will. Peinlich auch, dass die “doc”-Datei mit Writer und nicht mit MS Word erzeugt worden war. Ursache des Fehlers ist wie so oft eine Änderung in der Berechnung der Tabellenposition – besonders hart trifft der Bug Tabellen, die im Originaldokument etwas über den Rand des allgemeinen Textbereichs hinaus verschoben positioniert waren.

Wenn man ins Detail gehen wollte, könnte man an dieser Stelle noch eine Seite lang über wechselnde Positionen von Absätzen, Tabellen und Tabelleninhalten je nach 3.x-Version von OO berichten. Dafür bin ich heute aber zu müde.

Fazit: Eine bessere QS würde dem OO-Projekt gut tun

Liebes OO-Entwicklungs- und Release-Team! Bitte verbessert eure QS! In produktiven Umgebungen müssen sonst nämlich der Admin oder im schlimmeren Fall die Anwender Beta-Tester für neue OO-Versionen spielen. Das erinnert an MS, kostet einfach zu viele Nerven und verbessert den Ruf von OO überhaupt nicht. Es passt auch nicht zu den vollmundigen “latest und greatest” -Beschreibungen von neuen OO-Releases, die man auf der OO-Website lesen muss.

Ich kann jedem Admin nur raten, sich ein paar Werkstudenten zu holen und jede neue OO-Version gründlich und ausführlich zu testen, bevor er sie produktiv schaltet.
Dabei lohnen sich besonders Tests älterer Dateien und der Blick auf die Formatierung der dortigen Inhalte wie auch Tests von Dokumenten, die mit älteren OO-Version in MS-Formate umgewandelt wurden und nun mit einer neuen OO-Version geöffnet werden.

Einstweilen warten wir bei anracon auf die Version 3.1.1 !