Sonderzeichen unter 3.5beta2 falsch, unter 3.4.2 aber korrekt angezeigt

Hallo Liste,

weiss jemand wie folgendes Phänomen zu interpretieren ist?

Ich habe ein paar ältere Dokumente längere Zeit nicht geöffnet. Jetzt hab ich
eins gebraucht und unter LOdev-3.5beta2 festgestellt, dass bestimmte
Schriftzeichen nicht korrekt dargestellt werden.

Zum Test hab ich das Dokukment mit der Libre-Version meiner Distri (3.4.2 von
openSUSE 12.1) geöffnet - dort wurden alle Zeichen korrekt dargestellt.

Die beiden Versionen verhielten sich also offensichtlich unterschiedlich
bezüglich der Darstellung bestimmter Zeichen.

Da fiel mir ein, dass ich bei meinem zwischenzeitlich neu installierten System
vergessen hatte, genau diesen TT-Font zusätzlich zu installieren, der für die
obigen Zeichen benötigt wurde - daher war das Verhalten der beta2 auch nicht
weiter verwunderlich.

Mich wundert aber natürlich das unterschiedliche Verhalten der beiden
Versionen - woher konnte die 3.4.2 die Zeichen "nehmen", während das die
3.5beta2 nicht konnte???

Kann mir das jemand erklären?

(Inzwischen hab ich die Schriftart nachinstalliert und die Anzeige in der
beta2 ist erwartungsgemäß ebenfalls fehlerfrei.)

Gruß Nino

Hallo,

behaupte einfach mal es liegt an der Beta, weil noch nicht fertig.

Wie wurde es früher mal gemacht bei Sonderzeichen?

War der Font installiert ging die Anzeige schnell, weil die Zeihen ja alle da.
War er nicht installiert war das Programm gefragt. Die wirklich guten Programme hatten sich zwar nicht alle möglichen Fontzeichen einmal mir abgespeichert sonder nur die verwendeten.
Also konnte ich auch auf einem völlig leeren PC mir die Datei anschauen. Wirklich Sinn hatte es nur als der PC hat laufen lernen und noch nicht alles mögliche was ich vielleicht habe brauchen können installiert wurde weil der Speicheplatz ja klein war. Da gab es dann Fontsammlungen.

Aber lassen wir das, das dürfte aber der Grund sein warum es mal funktioniert und mal nicht.

Gruß
Christian

Hallo Christian,

ich zitiere mal nur das Wichtige:

... behaupte einfach mal es liegt an der Beta ...

(genau um das zu klären habe ich ja diese Mail geschrieben)

... früher mal ...

... guten Programme hatten ... Fontzeichen ... abgespeichert ...

Hilft das für das beschriebene Phänomen weiter?

Würde zur These führen: die openSUSE-3.4.2 speichert (manche?) Fonts ab, die
3.5beta2 kann das aber nicht.

Aber lassen wir das, das dürfte aber der Grund sein warum es mal
funktioniert und mal nicht.

Danke trotzdem erst mal fürs Mitdenken :slight_smile:

Wie könnte man denn herausbekommen, ob deine Vermutung bzw. die obige These
zutrifft oder nicht?

Gruß Nino

Hi Nino, *,

weiss jemand wie folgendes Phänomen zu interpretieren ist?

Nö - einfacher wäre es gewesen, hättest Du die Datei nach PDF
exportiert, um zu sehen welche(r) Font(s) tatsächlich verwendet werden
- vielleicht deinstallierst Du den Font nochmal und holst das nach...

[...]
Mich wundert aber natürlich das unterschiedliche Verhalten der beiden
Versionen - woher konnte die 3.4.2 die Zeichen "nehmen", während das die
3.5beta2 nicht konnte???

Wiegesagt - im PDF hätte gestanden woher (aus welchem Font) - nun was
Unterschiede sein können:
* VCL.xcu / das LO-eigene Font-Fallback - aber unwahrscheinlich, wenn
es ein "Spezialfont" ist. Aber möglich, wenn eine andere Grundschrift
verwendet wird, daß der Fallback einen anderen Pfad nimmt...
* Schriftersetzungs-Einstellungen in den Optionen
* Schrift wurde zu LO 3.4 explizit hinzugefügt
(~/.libreoffice/3/user/fonts z.B. oder zusätzlicher Font-suchpfad) &
distro-Version nimmt anderes Profilverzeichnis als vanilla (da könnte
man auch die pspfontcache Dateien vergleichen)

Kann mir das jemand erklären?

Du hattest doch noch irgendwo eine Schriftart, die die Zeichen enthält.
Warum das fallback bei der einen Version funktioniert, bei der anderen
nicht, dazu siehe oben.
Prinzipiell fragt LO fontconfig nach einem Font, wenn es selbst keine
explizite Fallbackregel hat.

ciao
Christian

Hallo Christian, *,

> weiss jemand wie folgendes Phänomen zu interpretieren ist?

Nö - einfacher wäre es gewesen, hättest Du die Datei nach PDF
exportiert,

ha - danke für diesen Tip! Das ist wirklich aufschlussreich (auch wenn ich mit
dem PDF-Quelltext selber nicht allzuviel anfangen kann, die Fontnamen stehen
aber im Klartext drin).

um zu sehen welche(r) Font(s) tatsächlich verwendet werden
- vielleicht deinstallierst Du den Font nochmal und holst das nach...

Das hab ich jetzt nochmal gemacht, ein "diff -a 35beta.pdf 342.pdf" ergibt
folgende Unterschiede an mehreren Stellen, im Prinzip:

-<</Type/FontDescriptor/FontName/CAAAAA+DejaVuSans-ExtraLight
+<</Type/FontDescriptor/FontName/BAAAAA+LiberationSans-Bold

bzw.

9 0 obj
-<</Type/Font/Subtype/TrueType/BaseFont/CAAAAA+DejaVuSans-ExtraLight
+<</Type/Font/Subtype/TrueType/BaseFont/BAAAAA+LiberationSans-Bold

später allerdings nochmal etwas anders:

12 0 obj
-<</Type/FontDescriptor/FontName/BAAAAA+LiberationSans-Bold
+<</Type/FontDescriptor/FontName/CAAAAA+DejaVuSansCondensed

und
14 0 obj
-<</Type/Font/Subtype/TrueType/BaseFont/BAAAAA+LiberationSans-Bold
+<</Type/Font/Subtype/TrueType/BaseFont/CAAAAA+DejaVuSansCondensed

Das heißt doch wohl, dass die SUSE-342 in der Tat andere Fonts als die
Vanilla-35b2 verwendet. Und es sind zweifellos Ersetzungsschriften, denn die
eigentliche Zeichenformatierung lautet auf "Albertus MT Light", die taucht
aber nur dann auf, wenn ich das PDF bei vorhandener (installierter) Schrift
anfertige.

...

Du hattest doch noch irgendwo eine Schriftart, die die Zeichen enthält.
Warum das fallback bei der einen Version funktioniert, bei der anderen
nicht, dazu siehe oben.
Prinzipiell fragt LO fontconfig nach einem Font, wenn es selbst keine
explizite Fallbackregel hat.

Ich glaube, ich habe das jetzt so weit verstanden, danke.

Meine Frage ging auch ein wenig in die Richtung, ob es ein Bug in der 3.5 sein
könnte. Da aber mein Problem durch die Installation der "richtigen" Schrift
behoben wurde, bin ich jetzt erst mal zufrieden. Zur Frage, ob vielleicht eine
ungeeignete Ersetzungsschriftart gewählt wurde, kann ich nicht viel beitragen
und sie ist mir persönlich im Moment auch nicht wichtig.

Gruß Nino

Hi Nino, *,

> weiss jemand wie folgendes Phänomen zu interpretieren ist?

Nö - einfacher wäre es gewesen, hättest Du die Datei nach PDF
exportiert,

ha - danke für diesen Tip! Das ist wirklich aufschlussreich (auch wenn ich mit
dem PDF-Quelltext selber nicht allzuviel anfangen kann, die Fontnamen stehen
aber im Klartext drin).

Oh, die Liste der Schriftarten sieht man auch in den PDF-Betrachtern
in den Dokumentinfos, man muß also nicht in die Datei selbst
reinschauen.

Das hab ich jetzt nochmal gemacht, ein "diff -a 35beta.pdf 342.pdf" ergibt
folgende Unterschiede an mehreren Stellen, im Prinzip:

-<</Type/FontDescriptor/FontName/CAAAAA+DejaVuSans-ExtraLight
+<</Type/FontDescriptor/FontName/BAAAAA+LiberationSans-Bold

Wundert mich, daß einmal "Extra Light" und einemal eine "Bold"
Variante verwendet wird.

später allerdings nochmal etwas anders:

12 0 obj
-<</Type/FontDescriptor/FontName/BAAAAA+LiberationSans-Bold
+<</Type/FontDescriptor/FontName/CAAAAA+DejaVuSansCondensed

Hmm - da hilft es, das Dokument entsprechend zusammenzukürzen, daß nur
noch ein Wort/ein Zeichen übrig bleibt, dann fällt die Zuordnung
leichter.
Aber jetzt macht obige Ersetzung mehr sinn.
* Beide verwenden LibreationSans-Bold, und
* anstatt DejaVuSans Condensed wird DejaVuSans ExtraLight verwendet

das wäre schon viel plausibler.

Das heißt doch wohl, dass die SUSE-342 in der Tat andere Fonts als die
Vanilla-35b2 verwendet. Und es sind zweifellos Ersetzungsschriften, denn die
eigentliche Zeichenformatierung lautet auf "Albertus MT Light", die taucht
aber nur dann auf, wenn ich das PDF bei vorhandener (installierter) Schrift
anfertige.

Jo, und eine "light" schrift durch eine andere "light" Schrift zu
ersetzten ist naheliegender als eine "light" durch eine "Condensed"
Variante.

Ich nehme jetzt einfach mal an, daß die Passagen, die im Original mit
Albertus MT Light formatiert sind mit der Deja Vu Schrift ersetzt
werden, und nicht durch die Liberation Sans.

Meine Frage ging auch ein wenig in die Richtung, ob es ein Bug in der 3.5 sein
könnte.

So wie ich es sehe eher ein bugix. Light-Variante durch light Variante
ersetzten hört sich besser an, als sie durch eine Condensed-Variante
zu ersetzen.

Aber wiegesagt: Sollte die 3.5 die Libreation Sans Bold als Ersatz
verwenden, dann ist es doch eher ein Bug. Light mit Bold zu ersetzen
wäre total verkehrt.

ciao
Christian

Hallo Christian, *,

>> > weiss jemand wie folgendes Phänomen zu interpretieren ist?
>>
>> Nö - einfacher wäre es gewesen, hättest Du die Datei nach PDF
>> exportiert,
>
> ha - danke für diesen Tip! Das ist wirklich aufschlussreich (auch wenn
> ich mit dem PDF-Quelltext selber nicht allzuviel anfangen kann, die
> Fontnamen stehen aber im Klartext drin).

Oh, die Liste der Schriftarten sieht man auch in den PDF-Betrachtern
in den Dokumentinfos, man muß also nicht in die Datei selbst
reinschauen.

Tatsächlich :slight_smile:

Allerdings dauert das Öffnen des pdf mit Okular deutlich länger als per vim
auf der Shell :wink:

> Das hab ich jetzt nochmal gemacht, ein "diff -a 35beta.pdf 342.pdf"
> ergibt folgende Unterschiede an mehreren Stellen, im Prinzip:
>
> -<</Type/FontDescriptor/FontName/CAAAAA+DejaVuSans-ExtraLight
> +<</Type/FontDescriptor/FontName/BAAAAA+LiberationSans-Bold

Wundert mich, daß einmal "Extra Light" und einemal eine "Bold"
Variante verwendet wird.

Lag wohl eher daran, dass ich bei meinem Test-Text einen ganzen Absatz mit
möglicherweise mehreren Auszeichungen verwendet hatte. Jetzt nochmal mit einer
neuen Datei und nur einer Text-Zeile probiert: da wird nur noch die
BAAAAA+DejaVuSans-ExtraLight verwendet.

Die passt - ausreichend gut - zur Originalschrift.

...

Aber wiegesagt: Sollte die 3.5 die Libreation Sans Bold als Ersatz
verwenden, dann ist es doch eher ein Bug. Light mit Bold zu ersetzen
wäre total verkehrt.

Nach obigen Erkenntnissen kann diesbezüglich Entwarnung gegeben werden.

Danke für's Debug-Lotsen - auch wenn das Problem mal wieder eher vor dem
Bildschirm saß :wink:

Gruß Nino