Category Archives: LibreOffice, OpenOffice

Beiträge zu Office-Programmen

Ärgerliche Probleme der OO-Integration in KDE 4

Posted on by

Wieder mal was aus dem schönen, bunten Linux-Alltag. Diesmal zu Openoffice. In letzter Zeit schreibe ich nämlich mal wieder häufiger große Dokumente mit Openoffice Writer (Version 3.2). Leider hat man da unter KDE 4 nicht immer Grund zur Freude.

Hier ein paar der ärgerlichsten Problem, zu denen ich – bis auf eine Ausnahme – leider auch keine Lösung anbieten kann. Die Fehler sind z.T. schon länger bekannt, harren aber ihrer Behebung. Ob das an Problemen mit Qt-Bliotheken unter KDE liegt, kann ich nicht wirklich beurteilen. Ich meine aber, dass alle Punkte ein Zeichen für die problematische Integration von Openoffice (ggf. auch anderen GTK-Applikationen) in den KDE4-Desktop sind.

Fehler Nummer 1: Verzögerungen beim Aufruf der Speicher- und Öffnen-Dialoge

Auf meinem Opensuse 11.2 (64 Bit) mit KDE 4.4.3 ist OO aus den Opensuse-Repositories installiert. Als Standard ist in den OO-Einstellungen vorgegeben, dass für das Speichern von Dateien die KDE-Dialoge gezogen werden sollen. Die öffnen sich auch – oft allerdings erst nach mehreren Sekunden. Selbst nach dem Öffnen des KDE-Dialogs dauert es noch ein weiteres Weilchen, bis dann schließlich auch der Name der Datei editiert werden kann Dieses Problem haben auch andere beschrieben.

http://www.linux-club.de/viewtopic.php?f=24&t=108919&start=0

Was immer da abläuft, dieses Problem läßt sich noch relativ einfach durch folgenden “Trick” umgehen. Man aktiviere unter
“Extras > Optionen > Allgemein” in der Rubrik “Öffnen/Speichern-Dialoge” die Option “OpenOffice.org Dialoge verwenden”. Die Dialogfenster zum Speichern sehen nun etwas anders aus. Sie haben auch einige Nachteile – dafür arbeiten sie aber sehr schnell – wie man es als viel beschäftigter Benutzer gerne hätte. Auf meinem Laptop hat das geradezu Wunder bewirkt.

Fehler Nummer 2: Die OO Statuszeile – Elemente der Fußzeile erscheinen gar nicht oder verschwinden – z.B. bei Änderungen der Fenstergröße

Die Statuszeile im Fußbereich von Writer erscheint unter KDE seit einigen neueren KDE-Versionen 4.3X/4.4X und OO 3.2.X oft nicht mehr vollständig. Genauer: Der Fußleistenbereich ist schon da, aber von den üblichen Elementen erscheinen nur die Rahmen – kein Zoom-Tool, keine Anzeige der Seitenzahlen, keine Anzeige der Sprach etc. ….

Damit geht eine wesentlicher Teil an Information und nützlicher Funktionalität gerade für größere Dokumente verloren. Das Verhalten ist relativ irregulär: Beim Starten im Vollbildmodus ist die Leiste oft noch in voller Bestückung da – nach einigen Aktionen speziell bei Änderungen der Fenstergröße leert sie sich aber wieder. Manchmal hilft ein Klick in den Bereich der Leiste, wo man z.B. das Zoom-Tool erwartet, um es wieder zum Erscheien zu bewegen. Aber das wirkt nicht auf Dauer.

Ich habe mir das Ganze mal unter Gnome angesehen – dort gibt es keine Probleme. Also scheint es was mit der Integration in KDE 4.3/4.4 zu tun zu haben – möglicherweise mit der GTK-Unterstützung in Qt. Mir kommt es so vor, als ob Signale zum Update des entsprechenden Fensterbereichs nicht richtig umgesetzt werden. Als Benutzer finde ich das einfach nur ärgerlich – damit kann man auch keine Werbung für die Kombination KDE4.4 ud OO 3.2 machen.

Dieser Fehler erscheint unter Opensuse bislang unabhängig vom verwendeten Repository für die OO-Pakete (Stable-Zweig und Unstable-Zweig). Er ist auch unabhängig vom KDE-Theme oder den GTK-Einstellungen in den KDE “system-settings”.

Ich kenne hierfür keinen Umgehungstrick. Auch dieser Fehler ist keine neue Sache :

https://bugzilla.novell.com/show_bug.cgi?id=550979
https://bugzilla.novell.com/show_bug.cgi?id=567886

Siehe auch meinen Beitrag in einem Opensuse Forum unter

http://forums.opensuse.org/get-help-here/applications/433096-bugs-openoffice-3-2-a-3.html

Fehler Nummer 3: Checkboxen in den Untermenü-Dialogen – speziell von
“Ansicht >> Symbolleisten”

Die Checkboxen im Submenü für die Aktivierung/Deaktivierung der Toolbars erscheinen praktisch alle gesetzt, wenn man dieses Submenü öffnet. Das hat natürlich mit der Realität nichts zu tun, sondern ist ein Bug. Beim Überfahren der Submenü-Punkte mit der Maus wechseln die Checkboxen nämlich zum tatsächlichen Status. Auch hier liegt offenbar ein Problem in der Signalverarbeitung unter Qt/Gtk vor.

Ansicht beim Öffnen:
Bug_OO_Menue_1

Ansicht nach Überfahren mit der Maus
OO_Bug_Menue_2

Auch dieses Problem tritt unter Gnome und älteren KDE-Versionen (3.5.X) nicht auf. Es kam mit irgendeiner OO 3.2-Version. Auch hierfür kenne ich persönlich keine Lösung.

Fazit: Fehlende QS ?

Openoffice sollte aus meiner Sicht ein repräsentables Flagschiff im Opensource-Bereich sein. Das Gleiche gilt für KDE 4.4. Für den Anwender sind solche Fehler wie die oben beschriebenen deshalb nicht nur nervig – gerade wenn man von früheren Versionen was anderes gewohnt ist. Ich finde vielmehr, dass solche Dinge Zeit und Geld kosten und einer professonellen Arbeitsumgebung nicht würdig sind.

Man kann nun alles auf Schwierigkeiten mit KDE 4, Qt und auf Trolltech (bzw. inzwischen Nokia) schieben.

Aus meiner Sicht ist das aber nicht der Punkt. Ich glaube schlicht, das die Qualitätssicherung im Opensource-Bereich bei der Kombination von mehreren sich schnell entwickelnden und großen Projekten wie KDE 4 und OO 3.X nicht mehr funktioniert. Denn was ich oben beschrieben habe, ist nur die Spitze eines Eisbergs. Tatsächlich könnte ich mich Tage hinsetzen und ununterbrochen Fehler aus einer Vielzahl von Anwendungen melden. Kein Witz, leider. (Gerade stürzt z.B. Amarok beim Abspielen des vierten Stückes von einer CD aus unerfindlichen Gründen ab, … aber meine Meinung, dass Amarok 2 eh’ besch …en ist, wird sich sowieso nicht mehr ändern .. )

Es ist auch nicht so, dass man gar nicht unter Linux arbeiten könnte. Im Gegenteil. Aber mein Eindruck aus dem letzten Jahr ist zunehmend der, das der Power-User in einer Opensource-Umgebung nichts anderes als ein Beta-Tester wird – für die Einzel-Applikationen, für den Desktop insgesamt und die Integration der Anwednungen in diesen Desktop. Irgendwie fühle ich mich an unheilige Zeiten erinnert, als ich noch Microsoft-Produkte benutzt habe. Liebe Leute – es kostet einfach zuviel Zeit, sich mit solchen Fehlern herumzuschlagen !

Die große Frage ist, wer hier im Opensource-Bereich eigentlich versagt. Die Entwicklungsteams? Die Distributoren? Die Provider der Tools? Oder stößt Open Source mit seinen Tendenzen zur Selbstorganisation wegen der Komplexität der Projekte schlicht an die Grenzen?

Ich stelle nur fest, dass es die Leute am meisten trifft, die täglich mit Opensource-Produkten umgehen wollen oder müssen. Und in einer professionellen Linux-Umgebung mit mehreren hundert Anwendern möchte ich z.Z. nicht derjenige sein, der die Update-Politik für den Desktop verantworten muss.

Bei uns als sehr kleiner Firma kann man fast alles kompensieren. Bei großen Umgebungen mit vielen Benutzern geht das nicht mehr. Als Anwender bei uns stößt man auf Fehler, seufzt und denkt sich seinen Teil. Und dann sind unsere Systeme so
reichhaltig bestückt, dass man zur Not immer eine komplette ältere Installation booten kann. Aber diesen Luxus, mehrere Systeme parallel auf jedem Desktop vorzuhalten, kann man sich da draußen in größeren Betrieben kaum leisten.

Aber das Thema Upgrade/Update-Politik unter Linux ist ein eigenes Thema für sich.

Meine Hoffnung ist, dass es bald mal wieder eine Kombination aus KDE 4 und OO gibt, bei der OO rundum gut funktioniert. Die Hoffnung stirbt zuletzt … und solange halte ich auch KDE die Treue. Bemerkenswert fand ich letzte Woche nur den Kommentar eines Arbeitskollegen, der auf Gnome schwört: “Das neue Ubuntu ist echt nicht gut ….” Dabei stehen doch die wirklichen Änderungen im Gnome-Bereich erst an …

Ich merke schon, ich muss mal wieder was Positives schreiben. Werde ich tun. Versprochen…..

Ergänzung 30.05.2010: Was Positives – Problem 1 und 2 sind anscheinend behoben

Kaum lässt man Frust ab, passiert auch schon was. Gestern Abend habe ich mir die neueste verfügbare Openoffice-Version von Opensuses OO-“Unstable”-Repository geholt.

OpenOffice.org 3.2.1
OOO320m18 (Build:9502)
ooo-build 3.2.1.2

Faktisch sieht es nach ersten Tests so aus, als ob die oben beschriebenen Probleme 1 und 2 behoben sind. Die KDE-Dialoge für Öffnen/Speichern kommen schnell und sind sofort bedienbar. Und die Statuszeile ist nun wieder permanent sichtbar.
Nicht behoben ist allerdings der Punkt 3 : Die Checkboxen für die Toolbars werden beim Öffnen des Submenü-Dialogs immer noch mit falschen Flags angezeigt.

Aber: es tut sich was – was Positives ! Ich freue mich …..

Spellchecking, KDE 4, OO 3, Thunderbird

Posted on by

Wieder mal ein Beitrag aus dem bunten Linux-Alltag. Diesmal zum Thema Wörterbücher. Auch hier nimmt die Vielfalt und damit die Verwirrung des Anwenders zu, wie ich heute wieder erfahren durfte.

Das Vielfalts-Problem

Meine liebe Anne ist Norwegerin und benutzt ein Opensuse Linux mit deutschem KDE 4. Nun steht sie natürlicherweise immer mal wieder vor folgenden Aufgaben

  • Verfassen von E-Mails auf Norwegisch mit Thunderbird
  • Verfassen von E-Mails auf Norwegisch auch mal mit Kmail
  • Verfassen von norwegischen Texten mit Openoffice

In all diesen Fällen möchte sie natürlich gerne eine Prüfung der Rechtschreibung der Wörter in norwegischer Sprache vornehmen lassen, um Tippfehler schnell korrigieren zu können.

Leider ist es nun nicht so, dass für diese Aufgabe unter Linux/KDE ein einheitlicher Spell-Checking-Mechanismus herangezogen würde, der sich auch einheitlich bedienen ließe. Und deswegen lief bei der guten Anne heute das Linux-Frustrations-Fass mal wieder über – mit der unmissverständlichen Aufforderung, ihr gefälligst ein brauchbares Arbeitsgerät bereitzustellen.

Tatsächlich muss man feststellen, dass in puncto “spell checking” zur Verzweiflung des Anwenders eine Vielfalt blüht, die nicht nur applikations- sondern auch noch versionsabhängig ist. Und in den von meiner Frau benutzten Anwendungen muss man doch recht spezielle Schritte unternehmen, um zum Erfolg zu kommen.

So wurde bei Openoffice mit dem Übergang von OO 2.4 auf OO 3.0 von “myspell” auf “hunspell” gewechselt. Gleichzeitig kam für den Anwender (oder den Admin) die Notwendigkeit, “add-ons” installieren zu müssen. So mancher Admin, der sich nicht um individuelle EInstellungen kümmern mochte, vergaß allerdings, seine Kollegen/innen auf diesen Umstand hinzuweisen.

Ähnliches gilt für Thunderbird und Firefox; auch hier wurde mit der Version 3 auf “hunspell” gewechselt. Blöd nur, dass einige der für Firefox und Thunderbird bereits etablierten “add on” Wörterbucher – leider auch die norwegischen – wegen Kleinigkeiten eine ganze Weile lang nicht mehr mit Firefox Version 3.6 und Thunderbird Version 3.x kompatibel waren.

KDE 4 setzt dagegen auf die GNU “aspell”-engine, die “ispell” ablöste und mit UTF-8 umgehen kann. Hier müssen die notwendigen Basis-Einstellungen für eine Reihe von KDE-Applikationen nicht in den Applikationen selbst, sondern in den KDE-Systemeinstellungen vorgenommen werden.

Was also muss man unter Opensuse 11.2 und KDE 4.4.3 für die oben genannten Anwendungen genau tun, um z.B. ein norwegisches Spell Checking hinzubekommen?

Maßnahmen für KDE und damit auch für Kontact/Kmail

Man installiere (z.B. über Yast) zunächst die erforderlichen “aspell”-Sprach-Pakete (myspell-Pakete nutzen hier nix!). Im Fall von Norwegisch sind das die Pakete “aspell-nb” (bokmaal) und “aspell-nn” (nynorsk). Danach kann man unter KDE4 über die Systemeinstellungen

“Systemeinstellungen >> Land/Region und Sprache >> Rechtschreibprüfung”

kontrollieren, dass die Korrekturmöglichkeiten für die neuen Sprachen zur Verfügung stehen. Die “automatische Prüfung” aktiviert man über die entsprechende Checkbox. Einzelne KDE-Applikationen haben aber wieder eigene Schalter, die die Aktivierung oder Deaktivierung einer automatischen Rechtschreib-Prüfung während der Texteingabe steuern.

rechtschreib_KDE

Als Standardsprache haben wir in unserem
Fall “Deutsch” als Einstellung belassen. (Wenn man aber eher Texte in einer anderen Sprache verfasst, lohnt sich ggf. eine andere Einstellung.)

Unter Kmail setzt man das Spell Checking für Norwegisch dann nach dem Öffnen des Mail-Editors für eine neue E-Mail wie folgt ein:

Erst einmal die “automatische Rechtschreibprüfung” über den Menüpunkt “Optionen >> automatische Rechtschreibprüfung” deaktivieren, um bei der Eingabe des norwegischen Textes nicht von vornherein durch irritierende rote Linien gestört zu werden. Danach die ersten Zeilen schreiben. Dann “Extras >> Rechtschreibung” wählen. In der Dialogbox die richtige norwegische Sprache auswählen und nach Bedarf korrigieren. Danach kann man übrigens die “Automatische Korrektur” auch wieder anschalten. Der Spell Checker merkt sich diese Einstellung für die aktuelle Mail.

Es gibt jedoch ein vereinfachtes Vorgehen: Im Kopf der zu verfassenden Mails kann man sich eine Combox anzeigen lassen, die einem eine Combox “Wörterbuch” zur Sprachauswahl für die zu erstellende Mail anbietet. Diese Anzeige steuert man im E-Mail-Editor über den Menüpunkt “Ansicht” und die dort verfügbaren Optionen.

rechtschreib_KDE_Kmail

Das vereinfacht den Einsatz des Spell Checkings pro Mail natürlich kolossal: Im Gegensatz zum oben beschriebenen “Umweg” über die Menüpunkte legt man die für die neue E-Mail geltende Sprache gleich nach dem Öffnen des Mail-Editors fest. Die automatische Korrektur kann dann immer aktiviert bleiben.

rechtschreib_KDE_Kmail_2

Die Combobox ist vor allem dann wirklich sehr nützlich, wenn man abwechselnd Mails in unterschiedlichen Sprachen erstellt und dabei fortlaufend den Spell Checker einsetzen will.

Maßnahmen für Openoffice (OO) 3.x

Zunächst prüft man mit Hilfe des Paketmanagers seines Vertrauens, dass “hunspell” installiert ist. Bei dieser Gelegenheit das Paket für den Openoffice-Thesaurus für “Norwegeisch-Bokmaal” installieren (Paket “OpenOffice_org-thesaurus-nb”), falls das Paket angeboten wird.

Danach ein aktuelles “Add-on” für die norwegische Sprache aus dem Fundus der OO 3 Extensions installieren. Fündig wird man auf der Webseite

http://extensions.services.openoffice.org/en/dictionaries

Von dort lädt man für das Norwegische das oxt-File

“dictionary-no-NO-1.0.oxt”

herunter und installiert es in OO 3.0 über den Menüpunkt “Extras >> Extension Manager”. Danach OO neu starten. (oxt steht für Openoffice extension).

Die Rechtschreibungprüfung steht unter OO 3 ggf. bereits über ein Symbol in der Haupt-Toolbar-Leiste zur Verfügung. Wenn nicht kann man sich die Leiste um das entsprechende Icon erweitern. Ansonsten benutzt man “F7” und/oder die Sub-Menüpunkte unter dem Menüpunt “Extras” :

“Rechtschreibung und Grammatik, Sprache, Language Tool”

Im Dialogfenster zur “Rechtschreibung und Grammatik” kann man schließlich die Sprache für die Analyse des Dokumentes oder eines markierten Abschnittes auswählen. In unserem Fall stehen nach Installation des oben genannten oxt-Files die zwei norwegischen Sprachen “bokmaal” und “nynorsk” zur verfügung. Die Anwendung der Rechtschreibhilfe im Rahmen des Dialog ist intuitiv möglich. Auch die (begrenzte) Prüfung der Grammatik kann
man aktivieren.

Für das Anschalten einer automatischen Prüfung ist ein Punkt unter “Optionen” im Dialog-Fenster zuständig. (Oder alternativ ein Icon in der Toolbar).

Erstellt man Dokumente mit Abschnitten, die in unterschiedlichen Sprachen verfasst sind, legt man die Sprache pro Abschnitt über den Menüpunkt

“Extras >> Sprache >> Für den Absatz ”

fest. Das ist aus meiner Sicht eine wirklich nützliche Funktion! OO merkt sich die Sprach- und damit auch die einzusetzenden Prüf-/Korrektur-Module für die jeweilige Sprache abschnittsweise.

Natürlich kann man aber auch die Sprache für das gesamte Dokument festlegen. Diese Einstellung oder noch globalere sind auch über

“Extras >> Optionen >> Spracheinstellungen >> Sprachen ”

und

“Extras >> Optionen >> Spracheinstellungen >> Linguistik”

möglich. Der letztere Menüpunkt gibt zudem einen interessanten Einblick in die verwendeten Sprach- und Hyphenation-Module – es lohnt sich, da mal reinzuschauen.

Maßnahmen für Thunderbird und Firefox 3.x

Der Entwickler Håvar Henriksen hat für Bokmaal und Nynorsk schon im Jahr 2008 geeignete Wörterbücher als Add-Ons zu den Mozilla-Applikationen zur Verfügung gestellt. Leider liefen diese eine Weile nicht mit den neuesten Versionen von FF und Thunderbird zusammen. In der aktuellen Form der Bereitstellung gibt es aber keine Probleme mehr. Die folgenden Schritte sind praktisch identisch für FF und Thunderbird:

Zunächst den Menüpunkt “Extras >> Add-ons ” anklicken.

Im sich öffnenden Dialog den Menüpunkt “Alle Add-ons ansehen” wählen . Auf der sich öffnenden Webseite in der rechten oberen Combobox den Punkt “Wörterbücher” für die Suche auswählen. Dann die Suche starten und in der Liste blättern. Ca. auf Seite 3 findet man dann die “Norsk Bokmaal ordliste”. Das entsprechende xpi-File

“norsk_bokm__l_ordliste-2.0.10.0-fx+tb+sm.xpi”

lädt man sich am besten auf seinen Rechner herunter (für den Fall späterer Neuinstallationen).

Danach wechselt man wieder zum immer noch offenen “Add-On”-Dialog-Fenster der Mozilla-Applikation (das Fenster hatte man mit “Extras >> Add-ons” geöffnet). Dort findet man links unten einen Button “Installieren …”, den man anklickt. Der Rest der Installation wird über Dialogboxen geführt; man sucht die eben heruntergeladene Datei und startet den Installationsvorgang.

In Thunderbird 3..0.2 bedient man sich des installierten Wörterbuchs nun über einen entsprechenden Punkt in der Toolbar. Hier verbirgt sich rechts neben dem Schalter übrigens (ähnlich wie bei Kmail) auch eine Combobox; diese erlaubt einem, das einzusetzende Wörterbuch für die jeweilige Sprache auf einfache Weise auszuwählen.

Ansonsten kommt man auch über den in diesem Zshg. missverständlich lautenden Menüpunkt “Einstellungen” zum Ziel. Dort findet man den Submenü-Punkt “Rechtschreibprüfung”, den man anklickt. Die sich öffnende Dialogbox ist einfach zu bedienen. Eine automatische Prüfung während der Texteingabe aktiviert man in Thunderbird über “Einstellungen >> Sofort-Rechtschreibprüfung”.

Fazit

Das Einstellen der Rechtschreibprüfung auf der Basis passender Wörterbücher zeichnet sich unter
Linux noch durch eine wenig anwenderfreundliche Heterogenität aus, ist aber durchaus möglich. Selbst meien Anne war nach getaner Arbeit zufrieden.

In diesem Sinne wünsche ich den Linux-Usern also viel Spass in Zukunft beim Einsatz des “Spell Checkings” für unterschiedliche Sprachen unter KDE, Kontact/Kmail, Openoffice und Firefox/Thunderbird !

Von den Entwicklern wünsche ich mir dagegen eine Strategie zur Vereinigung der “Spell Checking”-Verfahren.

Anhang 1 – Tastaturlayouts nicht vergessen!

Unter KDE ist es natürlich flankierend wichtig, Tastatur-Layouts einzurichten. Das Norwegische kennt wie vele andere Sprachen auch Sonderzeichen, die auf bestimmte Tasten gelegt sind. Die Anne will beim Tippen in norwegischer Sprache natürlich so arbeiten wie auf einer norwegischen Tastatur.

Zu den Tastatur-Layout-Einstellungen gelangt amn unter KDE 4 über die “Systemeinstellungen >> Land/Region und Sprache >> Tastaturlayout”. Im Dialogfenster aktiviert man die gewünschten Tastaturbelegungen für unterschiedliche Sprachen und das Anzeigesymbol in der KDE Kontroll-Leiste. Da Leute wie die Anne mit unterschiedlichen Anwendungen in unterschiedlichen Sprachen arbeiten, habe ich ihr unter dem Reiter “Umschalt-Einstellungen” das Umschaltverfahren auf die jeweilige “Anwendung” bezogen eingestellt – statt der Einstellung “Global”, die die Sprache für die gesamte Oberfläche und alle Anwendungen umschaltet.

Anhang 2 – KDE-Koffice-Frust

In den aktuellen Koffice2-Programmen funktioniert das Spell Checking unter Opensuse 11.2 und KDE 4.4 überhaupt nicht.

Aber das ist eh’ egal, weil die Koffice-Entwickler nicht willens sind oder zu wenig Ressourcen haben, um das grauenvolle Font-Rendering unter Koffice 2 abzustellen. Die wiederholten Hinweise im Web, doch für KOffice2 bitte das Subpixel-Hinting bei der Font-Glättung abzustellen, ist einfach indiskutabel. Hier wedelt aus Anwendersicht der Schwanz mit dem Hund. KOffice2 soll sich bitte in KDE einfügen und seinen Einsatz nicht von einer Maßnahme abhängig machen, die zur Verschlechterung der Schriftendarstellung auf der gesamten Oberfläche führen würde. Tja, der User hat’s mit einigen KDE-Entwicklern nicht immer leicht. Sorry ….

Links

http://en.wikipedia.org/wiki/MySpell
http://en.wikipedia.org/wiki/Hunspell
http://en.wikipedia.org/wiki/GNU_Aspell

Ärger beim Wechsel von OO 2.4 zu OO 3

Posted on by

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 !

Openoffice 3.0 unter MS Win mit Samba-Zugriff

Posted on by

Am 21.10.2008 habe ich in diesem Blog einen Fehler von OO 2.4 für MS Win beschrieben. Dabei ging es um erhebliche Verzögerungen beim Speichern von Dateien, welche auf Samba-Servern lagen und auf die direkt mit Openoffice zugegriffen wurde (also über die Windows-Netzwerkumgebung).

Inzwischen habe ich auf dem Windows Client OpenOffice in der Version 3.0 installiert. Der früher beschriebene Fehler tritt in dieser Version nicht mehr auf! Gut so!

Openoffice 2.4 unter MS Win mit Samba-Zugriff

Posted on by

Beim zunehmenden Einsatz von Openoffice im Unternehmen werden auch die Windows-Mitarbeiter gezwungen, sich immer mehr Dokumenten zu widmen, die unter Linux mit Openoffice erstellt wurden. Bei uns z.B. werden etliche Openoffice-Dokumente über zwei Samba-Server unter Linux (SLES 9 und Opensuse 10.3) bereitgestellt. Leider funktioniert der direkte Zugriff auf die entsprechenden Samba-Freigaben im Netzwerk von einem MS Win Client aus mit OO 2.4 nicht immer reibungslos. Die meisten Probleme – auch das nachfolgende – lassen sich aber durch einen einfachen Trick umgehen:

Fehler: Lange Verzögerungen beim Speichern von OO-Dokumenten auf Samba-Shares
Wie von anderen Dateien und Programmen her gewohnt, öffnet z.B. meine Frau und Mitarbeiterin oftmals Dateien direkt über den Windows-Datei-Explorer, indem sie die entsprechende Datei unter der Netzwerkumgebung sucht und dann anklickt. Ihr fiel nun auf, dass beim Speichern von Office-Dokumenten, die sie direkt über einen solchen Zugriff auf eine Freigabe in der Windows “Netzwerkumgebung” geöffnet hatte, manchmal mit einer deutlichen Verzögerung von bis zu 10 Sekunden zwischengespeichert wurde. Dies geschah ausschließlich bei Openoffice-Dokumenten.

Fehlerursache:
Misstrauisch geworden, habe ich mir dann die Fehlerlogs des Samba-Servers angesehen und ein paar Experimente angestellt. Ergebnis:

Beim Initiieren des Datentransfers durch Openoffice muss der richtige Samba-Service (sprich die Freigabe) angesprochen werden. Hierbei wird leider regelmäßig genau das letzte alphanumerische Zeichen des Service, der über den Dateiexplorer bzw. den “Öffnen”-Dialog von Openoffice unter MS Win gewählt wurde, nicht an den Server übermittelt. Dies ist im Samba-Fehlerprotokoll und auch über Ethereal nachweisbar.
Ich halte das für einen Bug der bei mir installierten Openoffice-Version.

Mir ist dabei übrigens nicht klar, aufgrund welcher Mechanismen das Speichern schließlich doch gelingt. Das erscheint mir sehr dubios und wäre auch unter Sicherheitsaspekten sicher eine weitergehende Analyse wert, für die mir aber gerade die Zeit fehlt. Festzuhalten ist nach ein paar Recherchen im Internet wohl Folgendes:

1) Openoffice unterstützt Samba bzw. CIFS nativ nicht wirklich korrekt.
2) Es gab und gibt sowohl unter Samba als auch bei NFS Probleme mit dem jeweiligen File-Locking-Mechanismus.
3) Das oben beschriebene Problem, bei dem nach meinem Verständnis eigentlich Windows den Zugriff auf den Samba-Share vorwegnimmt, ist ggf. ein zusätzliches.

Umgehung des Problems:
Der Fehler lässt sich unter MS Win XP (SP3) komplett umgehen, indem man Openoffice einfach jede Arbeit für den Remote-Zugriff abnimmt. Man benutze dazu vorab die Möglichkeit des Dateiexplorers zum Verbinden eines Netzlaufwerks unter dem Menüpunkt “Extras -> Netzwerklaufwerk verbinden …”. Dann gibt es keinerlei Probleme und auch das Fehlerprotokoll des jeweiligen Samba-Servers bleibt frei von Fehlermeldungen.

Hinweis zum Zugriff auf Samba-Ressourcen unter Linux:
Auch unter Linux (speziell für Debian und Ubuntu) sind in Foren des öfteren Fehler und Probleme beim Zugriff auf Dateien in Samba-Freigaben geschildert worden. Darunter auch der oben beschriebene Verzögerungseffekt beim Speichern. Inwieweit diese Probleme eine ähnliche Ursache haben, haben wir nicht untersucht.
Unter Opensuse ist mir persönlich hier nie etwas aufgefallen. Dies liegt aber evtl. daran, dass ich hier eine native Unterstützung des CIFS-Protokolls sowieso nicht voraussetze und die erforderlichen Samba-Freigaben immer vorab im Linux-Dateibaum mounte (oft per Smb4K). Dies entspricht dem oben beschriebenen Verfahren; auch hier nehmen wir Openoffice die Samba-Interaktion ab.

Hinweis zum Zugriff auf Openoffice-Dokumente auf einem OX5-Server
Ein Umfeld, in dem der Remote-Zugriff auf Openoffice-Dateien von “Konqueror”
aus immer scheitert, ist übrigens der der OX5-Groupware-Server. Dieser bietet Dateien über eine Weboberfläche und entsprechende Java-Scriptlets an. Konqueror setzt nun voraus, dass Openoffice den Zugriff auf die Resource des Webservers selbst handhaben kann Dies kann Openoffice nachweislich aber leider nicht. Firefox hingegen geht hier so vor, dass es die betreffende Datei herunterlädt und in einer temporären Datei des Linux-Systems zwischenspeichert. Mit dieser temporären Datei kann Openoffice dann wieder anstandslos arbeiten. Ich habe den Fehler gemeldet, aber bisher weder von den KDE noch den OO- oder OX5-Leuten eine hinreichende Resonanz erhalten. Es hilf der Einsatz von Firefox oder unter Konqueror auch ein Zugriff über die WEBDAV-Schnittstelle des OX5 . Dies führt hier aber zu weit.