Category Archives: LibreOffice, OpenOffice

Beiträge zu Office-Programmen

Opensuse Leap 15.4 on a PC – II – Plasma, Gnome, flatpak, Libreoffice and others on (X)Wayland?

Posted on by

In the last post of this series

Upgrade to Opensuse Leap 15.4 – I – a look at repositories, Nvidia, Vmware WS, KVM, Plasma widgets

we saw that an upgrade from Leap Opensuse 15.3 to Leap 15.4 is a relatively smooth operation. After the basic upgrade I wanted to look a bit at an interesting detail – namely (X)Wayland. And got surprised – positively and negatively. This post summarizes some of my experiences.

Nvidia and Wayland

For a long time it was almost impossible to use Wayland in combination with Nvidia and KDE. Which mostly was the fault of Nvidia. See an Heise article on this topic here. See also the experience of a Gnome user here – although I do not share his bad experience with a X11-based KDE Plasma on Nvidia. For years I have not seen a realistic chance for a productive use of Wayland on my PCs and laptops with Nvidia-cards. KDE PLasma did not work at all on Wayland. Also with Gnome I experienced terrible difficulties. But Nvidia has improved its support for Wayland significantly in 2022, starting with driver version 470. For Nvidia driver version 525 we would expect some stability.

Continue reading →

Libreoffice 6.0 und 6.1 Draw unter KDE/Plasma und Gnome – mit gtk3-Unterbau viel zu langsam

Posted on by

Einer meiner treuen Begleiter war Libreoffice Draw. Aber nach dem Upgrade auf Opensuse Leap 15 hatte ich damit beim Arbeiten mehr Frust als Lust. Ich muss z.Z. Skizzen einer Art neuronaler Netzwerke erstellen. Da kommen mal schnell 50 bis zu über hundert Einzelobjekte zusammen, die in großer Anzahl durch “Verbinder” aneinander gekoppelt werden müssen.

Das aktuelle Draw der Libreoffice Versionen 6.0 und 6.1 ist unter einem KDE-System mit GTK3 dafür aber viel zu langsam:

Klickt man auf das Symbol für “Verbinder” in der Leiste für Zeichnungstools, so dauert es auf hochauflösenden Schirmen (2K bis 4K) und bei komplexen Zeichnungen zwischen 4,5 und 8 Sekunden, bis die Zeichnung auf eine Darstellung mit allen Connector-Punkten der Objekte wechselt.

Ich habe nun wahrlich kein langsames System; auch die Speichereinstellungen für LO habe ich bereits (mühsam; s.u.) nach oben gesetzt. Während des Darstellungswechsels für Verbinder geht die Belastung des genau einen CPU-Kerns, den LibreOffice leider nur nutzt, kurzzeitig auf 100%.

Bei einer normalen “LO 6”-ImplementierungInstallation ist das Paket “libreoffice-gtk3” installiert; GTK3 wird dann automatisch gezogen. Ein gezielter Start für GTK3 ist im Terminal mit “SAL_USE_VCLPLUGIN=gtk3_kde5 libreoffice &” möglich. Nun kann man sich zusätzlich das Paket “libreoffice-gtk2” installieren und den Aufruf zu “SAL_USE_VCLPLUGIN=gtk_kde5” abändern.

Ein nachfolgender Test zeigt, dass die Zeiten beim Einsatz von GTK2 im Bereich von 2-3 Sek. liegen! Damit kann ich gerade noch leben. Weitere Tests offenbaren Folgendes:

Die Geschwindigkeit, mit der Draw die Anzeige von Connector-Punkten aller Objekte auf den Schirm bringt, hängt vom Zoomfaktor ab, mit der man sich das odg-Dokument anzeigen lässt; kleine und große Zoom-Faktoren machen den Umgang mit Verbindern bisweilen deutlich schneller.

Wer also große Diagramme mit vielen Objekten und Verbindern zeichnen will, sollte im Umgang mit Libreoffice 6.1 auf GTK3 verzichten. Zumindest unter KDE. Das kann man dort entweder durch den Aufruf

SAL_USE_VCLPLUGIN=gtk_kde5 libreoffice &

erreichen, oder aber indem man das Paket libreoffice-gtk3 deinstalliert und dafür das Paket “libreoffice-gtk2” installiert (neben libreoffice-qt5). Ein Verzicht auf gtk2 und gtk3 sowie eine alleinige Installation von libreoffice-qt5 führt vom Layout her übrigens in die GUI-Steinzeit. Ob das so richtig ist, mag ich im Moment nicht einmal recherchieren.

Nun habe ich auch das Rendern über OpenGL ausprobiert – funktioniert leider nicht => Schwarze Menüs. Ansonsten wäre der Aufbau der Zeichnung selbst etwas schneller …
Tests unter Gnome und LXDE brachten leider die gleichen Ergebnisse.

Ich hoffe auf Updates – und darauf, dass sich die LO-Entwickler endlich mal Gedanken darüber machen, an welchen Stellen sich Multithreading lohnen würde. Der Umgang mit Verbindern wäre da ein erstes gutes Betätigungsfeld. So wie der Stand im Moment im Zusammenspiel von Draw mit GTK3 aussieht, sind LO 6.0 und 6.1 jedenfalls eine Enttäuschung.

P.S. zum Thema Menü-Änderungen: Hinzu kommt der sich auch unter Kontact/Kmail ausbreitende Ehrgeiz von Maintainern, bewährte Menüpunkte für Programm-Einstellungen, die die Performance und die RAM-Nutzung einer Applikation beeinflussen, aus dem normalen Menübereich in eine völlig unübersichtliche und undokumentierte globale Parameter-Konfiguration zu verbannen. So geschehen bei Kmail; so geschehen bei LO.

Liebe Leute: Seit wann bieten wir dem User unter Linux weniger Optionen an?
Und seit wann wird Bewährtes und Verständliches in der Menüstruktur zugunsten unverständlicher und undokumentierter Parameter-Kaskaden aufgegeben? Bitte liebe LibreOffice-Teams: Hört mit diesem falschen Ehrgeiz an Options-Verlagerung und -Vernichtung auf … und kümmert euch lieber mal um die Performance.

Nachtrag 19.10.2018 zur Performance: Es ist inzwischen insgesamt ein wenig besser geworden (LO 6.1.3); dennoch geht das Arbeiten mit Verbindern in DRAW unter GTK2 immer noch schneller von der Hand als unter GTK3.

 

Libreoffice 6.0 unter Opensuse Leap 15 KDE/ Plasma – GTK3-Stil “Breeze” macht Probleme

Posted on by

LO ist eine GTK-Anwendung und nutzt in der Version 6.x GTK3. Wie ich kürzlich beschrieben habe, wollte ich u.a. Breeze als GTK3-Stil für GTK-Anwendungen unter Opensuse Leap 15.0 mit KDE/Plasma nutzen. Ursprünglicher Grund war die Suche einer verbesserten, kontrastreichen Darstellung von SWT-Bedienelementen unter Eclipse Photon mit Dark Scheme.

Leider musste ich heute feststellen, dass – zumindest bei mir – der Einsatz von Breeze als GTK3 Style mit der aktuelle Version 6.1.1 von LO zu Problemen führt: Der Scrollbar funktioniert nicht oder nicht immer zuverlässig. Keine Ahnung, was Ursache dieses Breeze-spezifischen Problems ist.

Wer also ein funktionierendes LO 6.1.1 unter KDE/Plasma haben will, sollte also z.B. auf “Adwaita” oder “Ambience” als GTK3-Style ausweichen. Beide Styles funktionieren im Gegensatz zu “Default” auch sehr gut mit dem Dark Scheme Eclipse Photon.

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

Posted on by

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

Posted on by

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.