Libreoffice 4.3.5, Opensuse 13.1, langsames Laden von Dateien bei nicht erreichbarem Printserver

Vor einiger Zeit klagten ein Kunde und ein Bekannter von mir darüber, dass sich Libreoffice [LO] beim Öffnen und erstmaligen Laden einer Datei sehr viel Zeit lasse. Wörtlich: Man kann sich erstmal einen Kaffe machen. Diese Meldungen trudelten bei uns sowohl für Windows- wie auch Linux-Systeme ein.

Ich konnte das zunächst nicht glauben; der Effekt ließ sich in unserem Netzwerk auf keinem PC oder Laptop (weder unter Opensuse 13.2 noch unter Opensuse 13.1) nachvollziehen.

Nun war ich vor kurzem ein paar Tage mit meinem Laptop (Opensuse 13.1 mit LO 4.5.3) unterwegs und musste selbst unter dem beschriebenen Problem leiden. Es dauerte einige Zeit, bis ich herausfand, was die Ursache war:

Ist

  • der Druck unter Linux oder Windows für einen Server konfiguriert
  • und wird für die Kommunikation zum Server z.B. das ipp-Protokoll eingesetzt
  • und ist irgendeine Netzwerkkarte aktiv, aber der aktuell eingestellte Druckerserver über das Netz nicht erreichbar,

so wartet Libreoffice zunächst minutenlang vergeblich auf Antworten von dem nicht zu findenden Drucker-Server, bevor es anfängt den Inhalt einer zu ladenden Datei zu rendern.

Ist dagegen ein Druckerserver oder ein lokaler Drucker erreichbar oder aber überhaupt kein Netzwerk aktiv, so öffnet LO die zu ladenden Dateien ohne Zeitverlust. In unserem Netz übernimmt ein permanent erreichbarer CUPS-Server die zentrale Ansteuerung verschiedener Druckerwarteschlangen; deshalb war das Problem auf Systemen innerhalb unseres Netzwerkes nicht nachvollziehbar.

Das Ganze ist natürlich für Libreoffice wenig werbewirksam. Liebe Libreoffice-Entwickler: Es soll tatsächlich Leute geben, die sich mit Ihrem Laptop zwischen verschiedenen Netzen daheim und am Arbeitsplatz bewegen – und manchmal ist halt keiner der eingestellten Drucker oder Druckerserver erreichbar, obwohl man z.B. an einem WLAN hängt. Dann sollte man nicht 3 bis 4 Minuten warten müssen, bevor eine simple Calc-Datei geladen wird.

Ein Workaround besteht bei Bedarf darin, die Druckereinstellungen (temporär) so umzustellen, dass erst gar nicht nach einem Netzwerkdrucker gesucht wird. Unter Linux ist das relativ einfach – unter Windows muss man sich durch die entsprechenden Punkte der Systemsteuerung quälen und die eingestellten Netzwerkdrucker entfernen. Das Dumme ist, dass man bei Rückkehr ins heimische Netz die Netzwerkdrucker wieder in den lokalen Druckeinstellungen aktivieren muss.

Ich denke, die Libreoffice-Entwickler haben hier wirklich etwas zu korrigieren. Es ist für Leute, die sich mit ihren Laptops evtl. täglich zwischen verschiedenen Arbeitsplätzen und Netzwerken hin und her bewegen müssen, nicht zumutbar, ihre Druckereinstellungen laufend anpassen zu müssen. Das Fehlen oder die Nichterreichbarkeit eines Druckerservers oder Druckers sollte nicht zum vollständigen Stopp des Datei-Ladens und -Renderns führen. Besser wäre hier ein Dialog, in dem der User über das Suchen nach dem Druckerserver informiert wird und ggf. diesen Schritt auch überspringen kann.

Hofen wir mal, dass das Problem mit einer der nächsten LO-Versionen wieder verschwindet.

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).