Opensuse 13.2, Libreoffice, fehlendes Paket libreoffice-clipart

Bestimmte Themen tauchen komischerweise immer wieder auf. Im Zusammenhang mit Opensuse 12.3 hatte ich vor ein paar Jahren darauf hingewiesen, dass zeitweise die deskriptiven Dateien "*.sdg, *.sdv, *.str, *.thm" für die thematische Gliederung der Openclipart-Dateien fehlten. Siehe
Opensuse 12.3 – OpenClipart-Definitionen für Libreoffice unvollständig

Im Moment ist es unter Opensuse 13.2 ähnlich schlimm:

Man kann zwar die Openclipart-Pakete herunterladen. Leider bietet aber keines der üblichen Repositories ein Paket an, dass dafür sorgen würde,

  • dass die Verlinkung der Clipart-Verzeichnisse in das zu Libreoffice gehörige "gallery"-Verzeichnis (/usr/lib64/libreoffice/share/gallery/) ordnungsgemäß vorgenommen wird
  • dass die notwendigen deskriptiven Dateien für die Themenfelder der Openclipart-Sammlung bereitgestellt werden.

Üblicherweise gab es hierfür in der Vergangenheit ein Paket namens "libreoffice-openclipart". Debian und Ubuntu bieten entsprechende, aktuelle "deb"-Pakete nach wie vor an. Bei SuSE ist das entsprechende RPM jedoch verschütt gegangen.

Deshalb sind vielen netten Openclipart-Bilder leider unter Libreoffice auf einem aktuellen Opensuse 13.2-System nicht unmittelbar und nicht ohne Klimmzüge nutzbar. Ich selbst merkte das natürlich auch erst, als ich für eine anstehende Kunden-Präsentation dringend ein paar Cliparts benötigte. Der in meinem früheren Beitrag erwähnte Workaround ist jedoch für die Menge der aktuellen Openclipart-Themenbereiche leider viel zu umständlich. Die alternativ einsetzbare Libreoffice-Erweiterung "openclipart.oxt" , mit der man ggf. Cliparts auch direkt aus dem Internet beziehen kann, finde ich viel zu träge. Man erhält aufgrund der notwendigen Suchvorgänge auch keinen schnellen Überblick. Ferner wird die Erweiterung seit längerem nicht mehr gepflegt. Was also tun ?

Möglicher Workaround
Man kann schlicht auf eine ältere Version aus Opensuse 13.1-Zeiten zurückgreifen. Ich habe mir z.B. aus dem Repository
http://rpmfind.net/linux/opensuse/distribution/13.1/repo/oss/suse/noarch/
die Pakete

  • openclipart-svg-0.18-155.1.2.noarch.rpm
  • openclipart-png-0.18-155.1.2.noarch.rpm
  • libreoffice-openclipart-4.1-2.1.3.noarch.rpm

heruntergeladen und in dieser Reihenfolge zusätzlich zum laufenden Libreoffice 4.3.5 installiert. Die Datei "libreoffice-openclipart-4.1-2.1.3.noarch.rpm" stellt dann wie gewohnt die erforderlichen deskriptiven Dateien bereit.

Danach ist u.U. noch ein wenig Aufräumen angesagt. In meinem Fall war es so, dass es im Verzeichnis "/usr/share/clipart" bereits ein Unterverzeichnis

"/usr/share/clipart/openclipart"

gab. Und zwar aus der früheren Installation der aktuellen Openclipart-Variante, zu denen Opensuse ja leider keine deskriptiven Dateien anbietet. Der Installer hatte die Dateien zur älteren Openclipart-Version 0.18 deshalb unter einem zusätzlichen Verzeichnis:
"/usr/share/clipart/openclipart-0.18"
angelegt. Das verträgt sich jedoch nicht mit den Links der deskriptiven Dateien. Also (als user root oder mit sudo):

mytux:~ # mv /usr/share/clipart/openclipart /usr/share/clipart/openclipart-0.20
mytux:~ # mv /usr/share/clipart/openclipart-0.18 /usr/share/clipart/openclipart

Danach noch checken, dass unter "/usr/lib64/libreoffice/share/gallery" die notwendigen deskriptiven Dateien der Openclipart-Themenbereiche tatsächlich als Links angelegt wurden - man erkennt diese (vielen) Links leicht am führenden "openclipart" im Namen. Ferner zur Sicherheit noch folgenden Link prüfen und ggf. ersetzen:

mytux:~ # rm /usr/lib64/libreoffice/share/gallery/clipart
mytux:~ # ln -s /usr/share/clipart/openclipart/ /usr/lib64/libreoffice/share/gallery/clipart

Nun mit dem aktuellen Libreoffice-Writer testen. Bei mir hat dann alles einwandfrei funktioniert. Ich bin damit zwar nicht auf dem neuesten Stand - kann aber wenigstens die Cliparts von Opensuse 13.1 nutzen.

Hoffentlich merkt ein Verantwortlicher bei Opensuse für das aktuelle Libreoffice-Repository bald mal, dass die dortigen Pakete nicht zusammen mit den Openclipart-Dateien funktionieren.

Libreoffice 4.1.6.2 – connection to remote cups server lost after 5 minutes

There are some bugs that seem to reappear again after some time in Libreoffice. One of these bugs is the handling of connections to remote cupsd servers and their printer queues. See:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=56344
https://www.libreoffice.org/bugzilla/show_bug.cgi?id=50784

The problem

In my present installation of Libreoffice 4.1.6.2 on an Opensuse 13.1 system with KDE 4.13 this bug reappeared. (The libreoffice packages are from the standard Opensuse 13.1 update repository). Currently the connection to our remote cups printer queues is lost after 5 minutes. This is the standard timeout for idle connections on the cups server (see the settings for the cupsd daemon). LibreOffice obviously does not reactivate the connection - at least not on my systems in their present status.

Deinstalled "libreoffice-kde4" as a cause ?

I did not check all and every LibreOffice setting that may influence this behavior. Furthermore, due to other problems with a previous LibreOffice release I had uninstalled the KDE extension package "libreoffice-kde4" on my machine - although I use KDE4. Instead I used the "libreoffice-gnome" package which worked more reliable for some aspects. So, I cannot exclude at the moment that the printing problem had to do with my deinstallation of "libreoffice-kde4".

The Kamppeter workaround may help

I had and have no intention to change my cupsd settings on the print server, because LibreOffice has a problem with reopening connections. What still helped in my situation and despite the deinstalled "libreoffice-kde4" was to change the print dialog from "LibreOffice dialog" to the standard system dialog. This workaround was described some time ago by Till Kamppeter; see "https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1020048/comments/33". It requires that one activates advanced options under
Tools >> Options >> LibreOffice >> Advanced >> Set Checkbox "Enable experimental features".

Then go to the "general" settings and deactivate "Use LibreOffice dialogs" under "print dialogs:
Tools >> Options >> LibreOffice >> General >> section "Print dialogs" >> Unset Checkbox "Use LibreOffice dialogs".

This worked in my case and maybe it helps others, too. If it does not I would also try to reinstall "libreoffice-kde4" again in case you use KDE4 (and see if it works better again than in some previous versions).

MariaDB, LibreOffice 4.x, Konnektoren – Performance Problem wg. Primary Keys

Vor einigen Tagen habe ich für ein Projekt verschiedene Varianten des direkten Zugriffs von Office-Anwendungen (MS Office, Libreoffice unter Windows und Linux) auf MariaDB -(MySQL-) Datenbanken eines Remote Linux-Server getestet. Dabei habe ich mir für LibreOffice [LO] unterschiedliche Konnektoren für den Datenbankzugriff angesehen - JDBC, ODBC und den direkten, nativen Zugriff über einen MySQL-Konnektor. Letzterer wird unter Opensuse -Linux mit dem LibreOffice RPMs mitgeliefert. Unter Windows steht der Konnektor dagegen als LO-"oxt"-Extension zur Verfügung. Siehe:
http://extensions.libreoffice.org/extension-center/mysql-native-connector-for-libreoffice-4.x/releases/1.0

Bei den Performance-Tests hatte ich dann ein Erlebnis der Sonderklasse, das sicher auch andere interessieren dürfte.

Testvoraussetzungen

Libreoffice habe ich mir in der Version 3.6, der Version 4.0.3 aus dem aktuellen LO Stable Repository des Build Services von Opensuse (12.3) unter Linux angesehen. Unter Windows die Versionen 3.6.7 und 4.0.6. Die Clients (Opensuse 12.3) und Windows 7 unter VMware liefen auf ein und demselben System mit einem i7 Quad 950 Prozessor und Raid-10-System. Der Server ist ein von Strato gehosteter V-Server mit 100Mbit -Anbindung ans Internet und 32Bit Opensue 12.3. Als RDBMS wurde eine MariaDB installiert, die bei Opensuse ja die Nachfolge des MySQL-RDBMS von Oracle angetreten hat.

Die Performance des Serversystems ist hinreichend - wir führen dort Simulationsrechnungen für industrielle Prozess- and Supply Chain Netze mit mehreren Zig-Tausend Knotenpunkten und mehreren zig-tausend Datenbanktransaktionen in wenigen Sekunden durch. Für das bisschen Transfer von Tabelleneinträgen im Bereich von 100 KByte bis zu wenigen MByte zu einem Client reicht die Serveranbindung völlig.

Alle Tests wurden mit SSH-Tunnelverbindungen zum Server durchgeführt. Wie man solche Verbindungen absichert, ist in einem vorhergehenden Artikel
https://linux-blog.anracom.com/2013/11/22/ssh-getunnelter-datenbankzugang-fur-gehostete-lamp-server-i/
ausführlich erläutert. Unter Windows wurden diese Verbindungen über PuTTY realisiert.

Die konkret untersuchten Tabellen hatten zwischen 200 und 220.000 Einträgen. Es handelte sich durchweg um MyISAM- und nicht um InnoDB-Tabellen.

Das Laden einer Datenbanktabelle erfolgt unter LibreOffice so, dass man über BASE Datenbankverbindungen zum RDBMS eines Remote-Servers definiert. Unter CALC läst man sich dann die definierten Datenquellen anzeigen (Taste F4), wählt eine Bank und eine zugehörige Tabelle aus. Deren Werte werden dann in einem besonderen oberen Bereich des CALC-Fensters zunächst als Base-Tabelle dargestellt, die man auch zum Ändern der DB-Werte verwenden kann. Der CALC-Schirm teil sich durch F4 also in einen oberen Bereich, der an Base angelehnt ist und einen unteren Bereich, der eine normale CALC-Spreadsheet-Tabelle enthält.

Der Import der Daten der DB-Tabelle erfolgt dann durch Drag und Drop der Tabelle aus der mittels F4 angezeigten Base-Tabellen-Liste in den darunter liegenden CALC-Spreadsheet-Bereich. Alternativ wählt man in der Base-Tabellen-Anzeige alle Werte aus, wählt ferner ein Zelle im CALC-Tabellen-Bereich als Startpunkt des Imports aus und betätigt dann eine Taste für den Import.

In der CALC-Spreadsheet-Tabelle wird dann ein mit der Datenbank assoziierter Bereich angelegt, der nach etwas Wartezeit mit den RDBMS-Tabellen-Daten gefüllt wird. Dieser mit der Datenbank verbundene Bereich kann später jederzeit mit den aktuellen Daten des RDBMS-Systems upgedated werden. Details hierzu findet man in der LO-Hilfe. Ich gehe hierauf in diesem Artikel nicht weiter auf di CALC-Anbindung an ein Remote-RDBMS ein.

Erste Tests: Erhebliche Performance-Unterschiede zu MS Excel ??

Der Schock entstand über einen Befund, den ich erst gar nicht glauben wollte. Nach etlichen Stunden, viel Konfigurationsarbeit und vielen Tests mit Zeitmessungen hatte ich folgendes Ergebnis vor mir:

Das reine Laden großer Datenbanktabellen über einen ODBC-Treiber schien unter Excel viel, viel schneller zu funktionieren als unter dem Gespann LibreOffice/Base/Calc mit direktem SQL-Konnektor.

Ich spreche hier wie gesagt von Tabellen mit 10.000 bis 220.000 Einträgen. [Das ist für die Belange des Kunden nicht besonders viel.] Und "schneller" ist dabei so zu verstehen, dass die Kombination Excel 2010/ODBC unter Windows 7 (64Bit) in den Tests zunächst erheblich - d.h. um Faktoren - schneller lief als jede Connector-Variante (ODBC, Direct MySQL-Connector, JDBC) mit Libreoffice/Calc/Base.

Dabei läuft Win 7 bei mir nur unter VMware. Die Linux-Tests wurden auf demselben nativen Linux-Host durchgeführt, der auch VMware beherbergt.

Ich nenne ein paar Zahlen für Tabellen mit ca. 14 Zahlenspalten (Integer, Double) :

  • Laden/Importieren Tabelle mit 224 Records : ca. 1 Sek.
  • Laden/Importieren Tabelle mit 6000 Records : ca. 8 Sek.
  • Laden/Importieren Tabelle mit 60.000 Records : ca. 95 Sek.
  • Laden/Importieren Tabelle mit 138.000 Records : ca. 4:40 Min.

Updates dieser per Base nach CALC importierten Tabellen dauerten etwa genauso lange. Den Versuch, eine Tabelle mit 250.000 Records zu laden, habe ich nach mehr als 10 Minuten Wartezeit abgebrochen. Ich merke ausdrücklich an, dass diese Zeiten nicht durch die übertragene Datenmenge über eine evtl. schlechte Internetanbindung erklärbar sind. Ferner gilt/galt:

Dem gegenüber stand eine Zahl für das Laden einer Tabelle mit 138.000 Records nach Excel per ODBC Konnektor von nur ca. 6-8 Sekunden.

Ich empfand diese extreme Diskrepanz zu Linux wirklich als unakzeptabel.

Man muss dazu sagen, dass die genannten Zahlen für das Linux-System bereits optimale Werte darstellen. Typischerweise ergaben sich auch sehr seltsame Effekte, wenn man zwischen den Tests die LO-Versionen durch Neuinstallationen der RPMs wechselte und die Konfigurationsdateien des aktuellen Linux-Users nicht komplett löschte. Teils lief dann das Laden auch kleiner Tabellen unter Calc unendlich lang. Ich deute diese Instabilitäten im Zusammenhang mit Up- oder Downgrades der RPMs - auch bei Auflösung aller Abhängigkeiten. Vielleicht ist das ein Hinweis darauf, dass irgendwelche Überbleibsel und Konfigurationseinstellungen nach einer Neuinstallation noch zu Interferenzen führen.

Die oben genannten Werte stellten sich nur ein, wenn man die jeweiligen Konfigurationsverzeichnisse im Home-Verzeichnis des Linux-Users nach einem Up- oder Downgrade vollständig gelöscht hatte. Ich konnte sie ferner nur für die 4.0.x-Version erzielen. Die Zeiten unter der 3.6 Version waren z.T. noch erheblich länger.

Schlechte Performance-Werte auch unter Windows

Der wirklich frustrierende Befund für die Datenanbindung von LO an eine MySQL-Datenbank wurde leider durch nachfolgende Tests für die LO-Versionen 3.6 und 4.1.3 unter Windows voll bestätigt.

Einschränkend sei angefügt, dass die Philosophie dessen, was ein Load/Import von Datenbankdaten leisten muss, vermutlich in Excel etwas anders ist als in LO. Aber beide Systeme verankern Datenbank-Verbindungen - in BASE geschieht dies innerhalb der Applikation, unter Windows werden die ODBC-Verbindungen über die Systemsteuerungen im Betriebssystem hinterlegt.

Excel lädt und importiert auf den ersten Blick eher passiv; auf der LO-Seite sind dagegen jederzeit Änderungen der DB-Inhalte und nachfolgende Updates aus der Datenbank für spezielle datenbank-assoziierte "Bereiche" von Calc-Tabellen möglich. Dennoch:

Schon beim Hantieren unter LO-BASE fallen die Geschwindigkeitsunterschiede ins Auge: BASE aktualisiert bereits beim Scrollen über große Tabellen die angezeigten Daten laufend im Hintergrund aus der angeschlossenen Datenbank. Ich habe keine Einstellung gefunden, das zu unterbinden. Vielleicht war ich dazu schlicht zu blöd.

Es zeigte sich unter Windows zudem, dass ein ODBC-Konnektor fast die gleichen Zeitwerte für den Datenbank-Import nach CALC lieferte wie die direkte MySQL-Anbindung durch den MySQL-Konnektor. Leider erwies sich die Performance einer JDBC-Anbindung noch deutlich schlechter als die der MySQL- und des ODBC-Konnektoren. Dass mindestens der ODBC-Konnektor aber eigentlich deutlich mehr leisten kann, beweisen gerade die hervorragenden Ladezeiten für Excel.

Performance-Problem des MySQL-Konnektors wegen Primary Keys?!

Die Frustration spornte mich zu weiteren Experimenten an. Ganz zufällig stieß ich dann bei weiteren Test unter Linux auf ein Tabelle mit 78.000 Einträgen. Überraschenderweise galt für diese Tabelle: Statt Minuten warten zu müssen, konnte ich die Tabellen-Daten in ca. 4-5 Sekunden über BASE/CALC in ein Calc-Spreadsheet laden.

Bei der weiteren Analyse stellte sich dann heraus, dass ich vergessen hatte, für diese Tabelle einen expliziten Primary Key festzulegen. Das führte zu dem Verdacht, dass explizit definierte Primary Keys evtl. mit verantwortlich für die schlechte Performance der LibreOffice-Anbindung waren - so idiotisch sich das auch anhören mag ....

Lösung: Ersetze Primary Keys durch Unique Keys !

Natürlich habe ich dann mal testweise auch in anderen Tabellen die explizit definierten PRIMARY Keys gedropt und durch schlichte UNIQUE-Keys ersetzt. Ja, das geht: MySQL oder Maria DB nehmen laut Doku stillschweigend den ersten passenden UNIQUE Key und setzen ihn als Primary Key ein. Große Probleme habe ich diesbzgl. bislang nicht erlebt.
Ergebnis meiner Versuche war:

Bei allen Tabellen, in denen der explizit gesetzte Primary Key durch einen reinen Unique Key ersetzt wurde, erfolgte der Daten-Import in LibreOffice-CALC mit annehmbaren Zeiten, die sich von denen von Excel nur noch wenig unterschieden (Faktor < 1,25).

Dabei ergab sich durch gleichzeitiges Beobachten der Datenbank und der Netzverbindung der begründete Eindruck, dass CALC nach dem eigentlichen Laden der Daten aus dem RDBMS noch erhebliche Zeit für den internen Aufbau der CALC-Tabelle aufwendet. Nurmehr Letzteres und nicht mehr das Laden der Daten aus der Bank selbst erwies sich für die vom Primary Index befreiten Tabellen als verantwortlich für die noch feststellbaren Zeit-Unterschiede gegenüber Excel beim Füllen der lokalen Spread-Sheet-Tabellen.

Konkret ergab sich für das Laden der Tabelle mit 138.000 Records eine Zeit von knapp unter 8 Sekunden - anstatt der früheren fast 5 Minuten.

In unserem Projekt habe ich nun in allen RDBMS-Tabellen explizit definierte Primary Keys durch Unique Keys ersetzt. Seitdem können die Anwender auch mit CALC prima auf der MariaDB-Datenbank arbeiten.

Offene Frage : Wieso behindern Primary Keys die LibreOffice Performance so drastisch?

Ich habe leider keine plausible Antwort. Diese Frage müssen die Entwickler der MariaDB klären. Auffällig ist die dauerhaft hohe Transaktionsrate auf dem Server von insgesamt über 200 Transaktion /sec, wenn ein Primary Key vorhanden ist.

Ich sollte abschließend noch betonen, dass ich den positiven Befund für das Entfernen der Primary keys explizit nur für eine MariaDB getestet habe. Es wäre sicher interessant, das Performance-Verhalten auch unter einer nativen Oracle-MySQL-Datenbank zu untersuchen. Hierfür habe ich leider noch nicht genügend Zeit gefunden.