Startseite
» MS OFFICE
»
Wie man benutzerdefinierte Schriftarten zu Collabora Online CODE Docker hinzufügt
Wie man benutzerdefinierte Schriftarten zu Collabora Online CODE Docker hinzufügt
Um eine benutzerdefinierte Schriftart in Collabora Online CODE (Collabora Online Development Edition) unter Docker verfügbar zu machen, müssen die Schriftdateien im Collabora-Container selbst verfügbar sein. Die Installation auf dem Docker-Host oder in einem separaten Nextcloud-Container reicht nicht aus, um sie auf dem Büroserver verfügbar zu machen. Für eine einzelne Compose-Bereitstellung ist eine schreibgeschützte Einbindung in der Regel die einfachste Option. Ein benutzerdefiniertes Image lässt sich leichter in einer verwalteten Umgebung reproduzieren, während die Konfiguration der Schriftarten über eine Remote-Verbindung die Bereitstellung zentralisieren kann, sofern dies sicher gewährleistet ist.
Die genauen Schriftartenverzeichnisse können je nach Image und Release variieren. Die aktuelle Helm-Bereitstellung von Collabora bindet benutzerdefinierte Schriftarten sowohl unter `/usr/local/fonts` als /usr/share/fonts/customauch unter `/usr/local/fonts` ein /opt/cool/systemplate/usr/share/fonts/custom. Dies ist eine nützliche Referenz für die beiden Speicherorte, aber keine Garantie für jedes eigenständige Docker-Tag. Überprüfen Sie die Pfade in dem Image, das Sie tatsächlich ausführen, bevor Sie das unten stehende Beispiel bereitstellen.
Welche Schriftartinstallationsmethode passt zu Ihrer Bereitstellung?
Wählen Sie anhand der Anzahl der von Ihnen verwalteten CODE-Instanzen, der Art der Aktualisierungsbereitstellung und der Fähigkeit, einen sicheren Schriftartenhost zu betreiben.
Verfahren
Optimale Passform
Abtausch
Schreibgeschützte Bindung
Ein Compose-Host oder eine kleine Installation
Einfache Aktualisierung ohne Neuaufbau, aber jeder Host benötigt die gleichen Dateien und kompatible Containerpfade.
Benutzerdefiniertes Docker-Image
CI/CD, wiederholbare Bereitstellungen oder mehrere verwaltete Hosts
Schriftarten werden zusammen mit dem Bild versioniert, aber das Ändern einer Schriftart bedeutet, dass sie neu erstellt und erneut bereitgestellt werden muss.
Remote-Schriftkonfiguration
Mehrere Instanzen, die einen zentral verwalteten Katalog benötigen
Die zentrale Bereitstellung führt zu einer Abhängigkeit von Diensten und Netzwerken; der Produktiveinsatz erfordert HTTPS und eine Absicherung des Betriebs.
Wenn Sie Collabora mit dem Helm-Chart installieren, überprüfen Sie zunächst die Chart- deployment.customFontsEinstellungen: Der Upstream-Chart bietet bereits eine Option zum Einbinden benutzerdefinierter Schriftarten. Bei einer eigenständigen Docker-Compose-Installation fahren Sie mit einer Bind-Mount-Verbindung fort, sofern Ihre Image-Pfade übereinstimmen.
Was sollten Sie vor einer Änderung an Docker überprüfen?
Schriftformat: Verwenden Sie Schriftdateien, die von Ihrer Collabora-Installation unterstützt werden. Das offizielle Collabora-Schriftserver-Projekt dokumentiert TrueType- .ttfund OpenType .otf-Dateien.
Lizenz: Vergewissern Sie sich, dass die Schriftartlizenz die serverseitige Nutzung und Weitergabe an Ihre Benutzer erlaubt. Kopieren Sie keine Schriftarten von einem Desktop-Betriebssystem, es sei denn, die Lizenz gestattet dies.
Familienname: Der im Schriftartenmenü angezeigte Name stammt aus den internen Metadaten der Schriftart und kann vom Dateinamen abweichen. Testen Sie daher den Familiennamen, nicht nur den Dateinamen.
Alle Instanzen: Wenn ein Proxy Benutzer an mehrere Collabora-Container weiterleitet, müssen auf jeder Instanz dieselben Schriftdateien installiert werden. Andernfalls kann dasselbe Dokument je nach Server, der es öffnet, unterschiedlich dargestellt werden.
Genaue Image-Pfade: Überprüfen Sie die Verzeichnisse und die Startkonfiguration des laufenden Images. Verwenden Sie nicht blindlings ältere Pfade /opt/looloder Pfade aus einem nicht zugehörigen Paket.
Erstellen Sie ein Verzeichnis wie beispielsweise ./fontsneben Ihrer Compose-Datei und legen Sie die zulässigen .ttfDateien .otfdarin ab. Beschränken Sie das Verzeichnis auf die Schriftarten, die Sie über Collabora verwenden möchten.
Der Ordner „fonts“ auf dem Host und die Compose-Datei, bevor das Verzeichnis zum Collabora-Dienst hinzugefügt wird.
Wie fügt man Schriftarten mit Docker Compose hinzu?
Fügen Sie die beiden schreibgeschützten Volume-Einträge zur volumesListe des bestehenden Collabora-Dienstes hinzu. Behalten Sie das aktuelle Image, die Ports, die Umgebungsvariablen und alle anderen Einstellungen des Dienstes bei; es handelt sich um eine Ergänzung, nicht um eine Ersatz-Compose-Datei.
Das Quellverzeichnis links befindet sich auf dem Docker-Host. Die Pfade rechts liegen innerhalb des Containers. Das :roSuffix macht die Dateien für den Container schreibgeschützt. Diese Zielpfade entsprechen der aktuellen Helm-Vorlage von Collabora. Bei eigenständigem CODE Docker überprüfen Sie bitte zuerst Ihren genauen Tag. Falls einer der Speicherorte fehlt oder Ihre Version andere Verzeichnisse verwendet, nutzen Sie die von diesem Image unterstützten Pfade, anstatt dieses Beispiel zu erzwingen.
Das Beispiel-Volume-Mapping sendet dasselbe Host-Schriftartenverzeichnis an beide Upstream-Collabora-Schriftartenspeicherorte.
Wenden Sie die Compose-Änderung während einer Ruhephase an, da das Neuerstellen des Collabora-Dienstes laufende Bearbeitungssitzungen unterbrechen kann. Wenn Ihr Dienst den Namen „Collabora“ trägt collabora, führen Sie Folgendes aus:
docker compose up -d collabora
Verwenden Sie Ihren tatsächlichen Compose-Dienstnamen, falls dieser abweicht. Vermeiden Sie einen vollständigen Neustart des Dienststapels, es sei denn, auch andere Dienste benötigen eine Konfigurationsänderung.
Wie kann man bestätigen, dass der Container auf die Dateien zugreifen kann?
Prüfen Sie zunächst, ob die eingebundenen Verzeichnisse die Schriftartdateien enthalten. Ersetzen Sie collabora<Containername> durch den in Ihrer Konfiguration verwendeten Containernamen:
docker exec collabora ls /usr/share/fonts/custom
docker exec collabora ls /opt/cool/systemplate/usr/share/fonts/custom
Beispiel für einen Verifizierungsbefehl: Listet beide eingebundenen Pfade im laufenden Collabora-Container auf.
Das Anzeigen der Dateien bestätigt zwar die Docker-Einbindung, beweist aber nicht, dass der Editor die Schriftart geladen hat. Falls das Image Fontconfig-Dienstprogramme enthält, können Sie die gefundenen Schriftfamilien fc-listbeispielsweise mit folgendem Befehl überprüfen:
docker exec collabora fc-list : family file
Filtern Sie die Ausgabe nach der erwarteten Schriftfamilie mithilfe eines im Container verfügbaren Tools. Falls dieses Tool fc-listnicht installiert ist, fügen Sie keine Pakete als dauerhafte Lösung zu einem laufenden Container hinzu. Überprüfen Sie stattdessen die Schriftkonfiguration des Images oder verwenden Sie ein reproduzierbares, benutzerdefiniertes Image. Wenn die Dateien zwar sichtbar, aber nicht erkannt werden, überprüfen Sie die Berechtigungen, das Dateiformat, die internen Metadaten der Schriftfamilie sowie beide Mount-Pfade. Konsultieren Sie anschließend die Protokolle für das exakte Image und die Version, die Sie bereitgestellt haben.
Wie testet man die Schriftart in Collabora Online?
Öffnen oder erstellen Sie ein Testdokument über die normale Integration, die Ihren Collabora-Editor startet.
Öffnen Sie das Schriftfamilienmenü und suchen Sie nach dem internen Familiennamen der Schriftart.
Wählen Sie es aus, geben Sie eine kurze Textprobe ein, speichern Sie, schließen Sie das Dokument und öffnen Sie es erneut.
Prüfen Sie dasselbe Dokument von einem anderen Benutzer oder Browser, falls Ihre Bereitstellung mehrere Collabora-Instanzen umfasst.
Das folgende Beispiel veranschaulicht die erwartete Prüfung: Eine Schriftart wird in einem Editormenü angezeigt. Es handelt sich nicht um eine Aufnahme aus einer laufenden CODE-Bereitstellung, und Ihre Symbolleiste kann je nach Version oder Integration abweichen.
Ein Beispiel für den Überprüfungsschritt: Prüfen Sie, ob die gewünschte Schriftart im Schriftartenmenü des Editors angezeigt wird.
Wird die Schriftfamilie zwar angezeigt, der Text jedoch in einer anderen Schriftart dargestellt, prüfen Sie, ob die ausgewählte Schriftart und -stärke (z. B. normal und fett) vorhanden sind und ob die Schriftart sowohl im Systempfad als auch im allgemeinen Schriftartenverzeichnis vorhanden ist. Ein Menüeintrag allein beweist nicht, dass die Schriftart in jedem Stil oder auf jedem Server verfügbar ist.
Wann lohnt sich ein individueller Bild- oder Schriftartendienst?
Erstellen Sie ein benutzerdefiniertes Image für die Wiederholbarkeit
Eine Dockerfile, die genehmigte Schriftdateien in die Pfade Ihres gewählten CODE-Images kopiert, vereinfacht die Reproduktion von Deployments: Der Image-Digest identifiziert sowohl den Server-Build als auch dessen Schriftsatz. Der Aufwand besteht in einem erneuten Build, Scan und Rollout bei jeder Aktualisierung einer Schriftart oder des Basis-Images. Überprüfen Sie die Zielverzeichnisse nach Aktualisierungen des Basis-Images erneut und vermeiden Sie es, eine Anweisung zum Kopieren von Schriftarten als versionsübergreifend für alle CODE-Versionen zu betrachten.
Verwenden Sie die Remote-Schriftkonfiguration für einen gemeinsam genutzten Katalog
Das Fontserver-Projekt von Collabora beschreibt die Konfiguration von Remote-Schriftarten und einen JSON-Katalog. Die Entwickler kennzeichnen dieses Repository als Entwicklungs- und Testumgebung; der Beispielserver sollte daher nicht für den Produktiveinsatz verwendet werden. Nutzen Sie für den Produktivbetrieb einen ordnungsgemäß gewarteten HTTPS-Endpunkt, beschränken und validieren Sie die bereitgestellten Schriftarten und berücksichtigen Sie die Netzwerkverfügbarkeit sowie das Aktualisierungsverhalten des Caches. Diese Vorgehensweise kann die Dateiverwaltung pro Host reduzieren, führt aber zu einem zusätzlichen Dienst, dessen Ausfall oder Konfigurationsabweichung die Verfügbarkeit von Schriftarten beeinträchtigen kann.
Für einen einzelnen, mit Docker Compose verwalteten CODE-Container empfiehlt sich zunächst eine schreibgeschützte Einbindung: Diese lässt sich einfach rückgängig machen und erfordert keinen benutzerdefinierten Build. Bei einer Flotte, die über CI/CD verwaltet wird, ist ein benutzerdefiniertes Image vorzuziehen, wenn jede Bereitstellung einen expliziten, überprüfbaren Schriftsatz enthalten soll. Die Konfiguration von Remote-Schriftarten sollte nur dann in Betracht gezogen werden, wenn die zentrale Verteilung einen wesentlichen betrieblichen Vorteil bietet und ein sicherer, zuverlässiger HTTPS-Dienst bereitgestellt werden kann. Überprüfen Sie in jedem Fall die Pfade und testen Sie die Schriftart nach der Bereitstellung in einem realen Dokument; die Schriftartenliste des Hosts allein reicht nicht aus, um zu bestätigen, dass Collabora die Schriftart geladen hat.