LibreOffice 5.3 – endlich ein Textverarbeitungsprogramm mit voller OpenType-Layout-Flexibilität!

[catfonts]

So gesehen ist der Mangel  ja fast schon als Vorteil anzusehen, überredet das doch den Nutzer zu einer sauberen Arbeitsweise mit Absatz- und Zeichenformaten.

[BerndH]

Leider habe ich in den nächsten Tagen nicht die Möglichkeit, diese (von mir seit langem ersehnte!) Funktionalität auszuprobieren, daher auf diesem Wege: 

Wie funktioniert die Ansteuerung der Funktionalitäten im Zusammenspiel mit der Auswahl der Fontdatei - der Schnitt, z.B. kursiv, wird ja im UI separat vom Schriftnamen angewählt, und es kann ja sein, dass z.B. der kursiv-Schnitt Swashes enthält, der regular-Schnitt nicht. 

Ist das egal, bzw. dann nur eine Inkonsistenz im UI, dass "Schriftname:feature" eingegeben wird und der eigentliche Schnitt, auf den sich die Auswahl des Features bezieht, in einem separaten Auswahlfeld bestimmt wird?

[Gast Arno Enslin]

vor 19 Minuten schrieb catfonts:

So gesehen ist der Mangel  ja fast schon als Vorteil anzusehen

Der Mangel, dass die Features nicht über eine Liste in der Benutzeroberfläche erreicht werden? Ich sehe das (auch) nicht als Mangel, sondern als Vorteil. Sogar als Riesenvorteil im Vergleich zu allem anderen, was mir bisher in Bezug auf die Ereichbarkeit der Features begegnet ist, die Adobe-Programme mit eingeschlossen. Nur das Eingabe-/Auswahl-Feld ist viel zu schmal. Ich würde die Benutzeroberfläche gerne mit CSS formatieren können wie die Benutzeroberfläche von Firefox.

 

Kurz gesagt: Dass rand noch nicht funktioniert, ändert nichts an meiner Begeisterung, zumal LibreOffice kostenlos ist.

 

Nachteilig ist die Eingabemethode allerdings für Menschen, die mit OT-Features nicht vertraut sind.

 

 

[Gast Arno Enslin]

Schön wäre noch, wenn LibreOffice beschreibende Namen für die ss-Features verstünde, wobei das nur mit UI Sinn macht.

[catfonts]

vor 25 Minuten schrieb Arno Enslin:

Nachteilig ist die Eingabemethode allerdings für Menschen, die mit OT-Features nicht vertraut sind.

Das war ja der Grund, warum ich hier von Mangel gesprochen hatte, da so diese eigentlich wunderbare Funktion den meisten Nutzern verborgen bleibt.

[Þorsten]

vor 3 Stunden schrieb BerndH:

Wie funktioniert die Ansteuerung der Funktionalitäten im Zusammenspiel mit der Auswahl der Fontdatei - der Schnitt, z.B. kursiv, wird ja im UI separat vom Schriftnamen angewählt, und es kann ja sein, dass z.B. der kursiv-Schnitt Swashes enthält, der regular-Schnitt nicht.

Das funktioniert so wie gedacht. Weist man ein Zeichenformat mit SchriftfamilieMitKursivenSchwungbuchstaben:swsh normalem Text zu, wird einfach der normale aufrechte Schnitt benutzt. Klickt man auf  i, kommen die kursiven Schwungbuchstaben. Genauso wie es z.B. auch mit CSS funktioniert.

[catfonts]

vor 3 Stunden schrieb Arno Enslin:

Kurz gesagt: Dass rand noch nicht funktioniert, ändert nichts an meiner Begeisterung

Das wäre für mich auch nur das absolute Oberbonbonchen gewesen, wenn ausgerechnet ein OpenSource und Freeware-Programm dem Leitwolf zeigt, wo der Hammer hängt. Aber vielleicht war es auch ein Kardinalfehler, überhaupt dieses Feature in die offizielle Liste auf zu nehmen, da es ja eigentlich überhaupt keine Software dafür gibt. Vielleicht hätte man besser etwas erfunden wie:

 

feature circ {

sub s from [s_1 s_2 s_3 s_4 s_5 s_6];

} circ;

 

und dann  wird durchgekreiselt, statt das aufwändig programmieren zu müssen.

 

[Gast Arno Enslin]

vor 54 Minuten schrieb catfonts:

und dann  wird durchgekreiselt, statt das aufwändig programmieren zu müssen.

Durchkreiseln erscheint mir jetzt auch nicht viel aufwendiger, als die Elemente zufällig auszuwählen. Bei einem circle-Feature müsste sich das Programm ja sogar die letzte Position in der Klasse merken. Beim Random-Feature muss nur die Anzahl der Zeichen in der Klasse ermittelt werden, um den Zufallsgenerator in Bezug auf die größtmögliche Zahl zu limitieren. Und der Zufallsgenerator selbst muss ja wahrscheinlich nicht programmiert werden, weil jede Programmiersprache einen Zufallsgenerator bereithält.

[catfonts]

stimmt auch wieder

 

[catfonts]

Aber vielleicht liegt das Problem bei "rand" ganz wo anders. Möglicherweise sind die Glyphen dann nämlich unterschiedlich breit, und dann sehe das Dokument bei jedem Öffnen möglicherweise unterschiedlich aus, weil jedes mal die Zufalls-Glyphen neu berechnet werden.

 

Bei der derzeitigen Praxis mit Pseudo-Zufall durch Glyphenrotation kommt aber immer die gleiche Reihung heraus. damit wird ein Dokument auch immer wieder gleich aussehen.

[Gast Arno Enslin]

FontReserve braucht 15 Sekunden länger zum Starten, wenn LibreOffice gestartet ist. Hatte ich noch nie. Ist aber reproduzierbar.

[Gast Arno Enslin]

vor 1 Minute schrieb catfonts:

Aber vielleicht liegt das Problem bei "rand" ganz wo anders. Möglicherweise sind die Glyphen dann nämlich unterschiedlich breit, und dann sehe das Dokument bei jedem Öffnen möglicherweise unterschiedlich aus, weil jedes mal die Zufalls-Glyphen neu berechnet werden.

Die Erklärung ist plausibel. Aber trotzdem sehe ich nicht, worin der Aufwand bestehen soll, das Problem zu lösen. Bis auf Weiteres gehe ich einfach davon aus, dass rand bisher nicht umgesetzt wurde, weil andere Dinge für die Programmierer Priorität hatten.

[catfonts]

Der Aufwand, das zu lösen wäre sicherlich, für diese Pseudo-Zufallszahl einen festen Startwert zu verwenden.

[Gast Arno Enslin]

Ich dachte eher an die Lösung, die durchgeführten Ersetzungen im Dokument abzuspeichern,  anstatt sie erst beim Öffnen des Dokuments durchzuführen. Im Dokument sollte also nicht nur gespeichert werden, für welche Textstellen ein Feature aktiviert ist, sondern auch, was das Feature bewirkt hat, Zeichen für Zeichen bzw. Zeichenfolge für Zeichenfolge. In Bezug auf den Speicherbedarf läuft das vermutlich auf dasselbe hinaus. Oder fast dasselbe. Beispiel:

 

Ligature: sub w udieresis r f e l  by x

Randomize: sub x from @wuerfel

 

Eingebener Text:

würfel

 

Im Schriftartenfeld ist Folgendes gewählt:

Wuerfelschrift:liga&rand

 

Das Programm ersetzt nun den eingebenen Text „würfel” durch eines von sechs Würfelsymbolen und der Code für dieses Symbol wird im Dokument abgespeichert. Außerdem wird im Dokument gespeichert, ob ein Zeichen Folge einer Ersetzung ist und falls ja, welche Features gegriffen haben. Das ist wichtig, weil man das Würfelsymbol auch direkt eingeben könnte, falls es Unicode hat. Und direkt eingegebene Zeichen sollen nicht als ersetzte Zeichen erkannt werden. Wenn das Dokument wieder geöffnet wird, wird das gespeicherte Symbol angezeigt.

 

Der User markiert nun das Würfelsymbol, klickt ins Schriftarten-Feld und entfernt „:liga&rand”. Und das Programm schaut dann in die Klasse @wuerfel, ob das Würfelsymbol darin enthalten ist. Falls ja, ersetzt es erst das Symbol durch x und dann x durch würfel. Das Programm macht das aber nur, falls das Würfelsymbol nicht direkt eingegeben wurde.

 

Verstehst du, worauf ich hinaus will?: Es scheint nicht nötig sein, dass im Dokument der Code für direkt eingegebene Zeichen gespeichert wird, wenn diese aufgrund eines Features ersetzt wurden. Und deshalb dürfte der Speicherbedarf nur unwesentlich größer sein. Ich bin mir nicht völlig sicher, halte das aber nach kurzem Nachdenken für wahrscheinlich, obwohl ich kein Programmierer bin.

 

 

[catfonts]

Das widerspricht aber der generellen OpenType-Ersetzung, bei der ja der ungeänderte Text immer gespeichert bleibt, um dadurch auch dann durchsuchbar zu bleiben, wenn Buchstaben z.B. durch Ligaturen, oder s durch ſ ersetzt wird. Das ist ja gerade der Vorteil einer OpenType-Ersetzung gegenüber einer reinen Verwendung von anderen Unicode oder gar hier PUA-Glyphen durch ein Zeichen-Ersetzungsprogramm, wie z.B. bei Frakturschriften Ligafaktur. Zudem würde es ja dann mit uncodierten Glyphen gar nicht mehr funktionieren.

[Gast Arno Enslin]

vor 8 Minuten schrieb catfonts:

Zudem würde es ja dann mit uncodierten Glyphen gar nicht mehr funktionieren.

Im Prinzip schon. Die Glyphenpalette in Indesign zeigt ja auch Zeichen an, denen im Font kein Unicode zugewiesen wurde. Aber ansonsten hast du wohl recht. Wenn das Dokument auf einem Rechner geöffnet wird, auf dem der verwendete Font nicht installiert ist, gäbe es ein Problem.

 

Edit: In dem Fall müssten im Dokument sowohl die eingegeben Zeichen als auch die ersetzten gespeichert werden. Und die Dateigröße würde steigen. Da aber in den seltensten Fällen alle Zeichen ersetzt werden, könnte ich mich mit etwas größeren Dateien anfreunden. Zumal das Problem ja nur beim rand-Feature auftritt. Es würde also ausreichen, wenn im Dokument außer den direkt eingegebenen Zeichen zusätzlich die durch das rand-Feature ersetzten gespeichert werden würden. Oder?

[Mueck]

Wie sieht's denn mit der Kompatibilität zwischen OpenOffice und LibreOffice aus?

Eigentlich wollte ich schon seit einer Weile mal mein OpenOffice auf meinem Winddows-7-Schlepptop aktualisieren ...

Ich glaube, ich aktualisiere bei der Gelegenheit auch mein LibreOffice ...

Vor laaaanger Zeit hatte ich mal überlegt, ob ich für unsere lokale Drei-Vereine-Zeitschrift 3x/Jahr, an der ich gerade wieder sitze, von OO auf LO umzustellen. Das habe ich dann aber sein lassen, weil mir das zu aufwändig war, in LO alles so hinzubiegen, dass es so funktoniert, wie ich es von OO gewohnt war. Weiß aber nicht mehr, woran es da klemmte. Aber man könnte es ja angesichts der neuen Entwicklungen noch mal versuchen ...

[Þorsten]

Garantieren, dass es gar keine Inkompatibilität gibt, kann ich natürlich nicht. Aber wir (in einer fast reinen Linux-Bude) benutzen seit 15 Jahren oder so überwiegend OOo und LO für alles, wofür unsere Kunden Word benutzen. Die Probleme zwischen verschiedenen OOo- und LO-Versionen waren immer erheblich geringer als innerhalb verschiedener Word-Versionen oder oft sogar verschiedener Word-Konfigurationen ein und derselben Version. Probleme zwischen OOo-Versionen und LO-Versionen gleicher Generation waren definitiv am geringsten von allen. (Ich erinnere mich nicht daran, dass überhaupt welche auftraten.)

[catfonts]

In diesem Zusammenhang stellt sich mir die Frage, ob man nicht ein LO-Plugin programmieren könnte, das folgendes macht:

1. die installiertzen Fonts anzeigen., im Grunde wie die Font-Auswahl des Programms selbst, aber...

2. bei Auswahl einer Schriftart diese Schrift nach OpenType-Tables durchsuchen, und vorhandene mit Auswahlbutton anzeigen, wobei standardmäzig aktive Features hier schon als markiert angezeigt werden, und dann...

3. wahlweise ein Zeichenformat oder ein Absatzformat anlegen kann.

 

Das müsste doch eigentlich kein unüberwindbares Hexenwerk sein, zumal LO ja eine Add-On-Schnittstelle anbietet - und ja auch OpenSource ist, und auch schon ein Typografie-Plugin für die Graphite-Funktionen verfügbar ist.

[Gast Arno Enslin]

vor 10 Stunden schrieb catfonts:

bei Auswahl einer Schriftart diese Schrift nach OpenType-Tables durchsuchen

Zur Präzisierung: Bei Auswahl einer Schriftart diese Schrift (bzw. den Font) auf das Vorhandensein einer GSUB-Table (Glyphen-Ersetzungs-Tabelle) überprüfen und falls eine GSUB-Table vorhanden ist, diese GSUB-Table nach allen darin enthaltenen Layout-Features durchsuchen. Die Layout-Features befinden sich ja ausnahmslos in der GSUB-Table.

 

Edit: Eventuell müsste noch überprüft werden, für welche Features für welche Sprachen verfügbar sind.

 

Wenn in der Einleitung des Features-Files nur »languagesystem latn TRK;« angegeben wird, dann wären die Features nur erreichbar, wenn dem Text die türkische Sprache zugeordnet wird. Wobei ich noch nicht ausprobiert habe, ob Makeotf eine Fehlermeldung ausspuckt, wenn »languagesystem DFLT dflt;« nicht angegeben wird.

[Gast Arno Enslin]

Ergänzung: Die GSUB-Table selbst enthält weitere Tables.

[catfonts]

In diesem Zusammenhang, es tut sich noch mehr in der OpenSource-Szene mit OpenType:

Scribus 1.5.3svn kann auch OpenType, ist aber eben ein svn-Build, also noch recht holprig und Lückenhaft - aber 1.6 wird OpenType umfassend können:

 

[Gast Arno Enslin]

Hat jemand mal versucht das Kerning in LibreOffice 5.3 auszuschalten? Das geht nämlich nicht über den Zeichen-Dialog, sondern nur, indem man das Kern-Feature über das Font-Menü ausschaltet (Schriftname:kern=0). Zumindest, wenn das Kerning in der GPOS-Tabelle gespeichert ist. Ob sich GPOS-Kerning und die klassische Kerning-Tabelle dabei in die Quere kommen können, also die Option »Paarweises Kerning« das in der klassischen Kerning-Tabelle enthaltene Kerning aktiviert, falls der Font eine solche Tabelle enthält, habe ich nicht getestet.