Schrift wird auf der Homepage auf allen Applegeräten falsch dargestellt

Das hat bei mir geholfen! Aber die Ursache ist mir noch nicht ganz klar.

Wenn ich im Webeditor (Wordpress) in der WYSIWYG Ansicht den fehlerhaften Umlaut entferne, steht anstelle des Umlautes (z.b. "ä") dann zunächst der korrespondierende Buchstabe (z.B. "a") dort obwohl ihn nicht eingetippt habe. Da wird also irgendetwas als "zwei Zeichen" behandelt. Im Webeditor (Wordpress) sehen die "defekten" und die "ersetzten" Umlaute jedoch komplett gleich aus, selbst in der "Codeansicht".

Sogar im ausgelieferten Webseitencode (betrachtet mit Firefox > Rechtsklick > Untersuchen oder Safari > Rechtsklick > Element Information ) sieht der Code der (beispielhaft) Worte <p>Gespräch</p> exakt(!) gleich aus. Da sind die Umlaute auch ohne urml etc. zu sehen.

Ich habe die "defekten" und die "ersetzten" Worte dann mal über die Webansicht vom Safari kopiert, in die MacApp "Textedit" einkopiert und die Datei als RTF gespeichert. Wenn ich diese Datei dann mit BBEdit oder TextWrangler öffne, sehe ich interessante Unterschiede in der Codedarstellung der Umlaute wie sie in Textedit "gelandet" sind:

Gsgespr\'e4ch - mit Umlautfehler

Gespr\'e4ch! - ohne Umlautfehler

Also entweder sind (oder waren) beide "Umschreibungen" mal gültig, oder eines der Tools mit denen der Text früher mal (vor dem herauskopieren) bearbeitet wurde ist damit falsch umgegangen. Soweit ich weiss, war im Prozess häufiger "Word" im Spiel.

Ich finde das insgesamt sehr interessant (besonders weil es im ausgelieferten Webcode identisch aussieht) und würde das daher gern weiter verfolgen. Hat jemand eine Idee wie das sein kann?

Kennt jemand ein Tool, dass mir kopierte Textinhalte (Zwischenablage) quasi "Raw" anzeigen kann?

Jedenfalls war die Idee die Umlaute "neu zu tippen" sehr hilfreich, Danke!

Überprüfen Sie die Schriftart-Datei, das CSS, die verfügbaren Schriftartenformate und die CORS-Einstellungen. Ein Cache-Problem oder spezifische Apple-Stile könnten ebenso die Ursache sein. Ein Fallback im CSS ist ebenfalls empfehlenswert.

• Es könnte sein, dass die selbstgehostete Schriftart-Datei nicht alle benötigten Zeichen enthält oder beschädigt ist. Sie könnten versuchen, eine andere Version der Schriftart herunterzuladen und sie erneut zu hosten.
• Überprüfen Sie, ob es in Ihrem CSS spezifische Stile gibt, die nur auf Apple-Geräten angewendet werden. Hier könnten Sie den font-weight überprüfen und sicherstellen, dass dieser nicht versehentlich auf bold gesetzt ist.
• Es gibt verschiedene Schriftartenformate (z.B. .woff, .woff2, .ttf, .otf). Einige Browser und Betriebssysteme bevorzugen bestimmte Formate. Stellen Sie sicher, dass Sie mehrere Schriftartenformate bereitstellen und diese in Ihrem CSS korrekt referenziert werden.
• Stellen Sie sicher, dass Ihre CORS-Einstellungen die Verwendung der selbstgehosteten Schriftart zulassen, insbesondere wenn die Schriftart von einem anderen Server geladen wird.
• Es ist immer eine gute Idee, Fallback-Schriftarten in Ihrem CSS anzugeben, für den Fall, dass die Haupt-Schriftart aus irgendeinem Grund nicht geladen werden kann.

Beste Grüße & Viel Erfolg!

Hi,

hast du den Text vielleicht von irgendwo kopiert wo die Umlaute komisch codiert waren? PDF oder sowas?

Hatte das gleiche Problem, die Umlaute manuell auszutauschen hat geholfen.

Auf meinem iPhone wird die Webseite im Übrigen korrekt dargestellt. Vielleicht auch mal den Safari (Webseiten) Cache löschen und Webseite neu laden. ;-)

Nachtrag: verwendeter Browser = Safari.

Hi tomjoz,

welchen Browser verwendest du denn? Ist das bei allen Browsern auf einem Apple Gerät der Fall oder nur bei einem Browser?

Auf meinem Windows PC mit EDGE sieht es ebenfalls nicht so aus als würde dein gewünschter Font korrekt geladen werden, sind diese überhaupt korrekt verlinkt?

Bedenke auch, je nach Voreinstellung des Browsers werden auch Fonts überschrieben.

Achse ok... im Quelltext bzw. der CSS ist noch die das Source Sans Pro Font verlinkt... oder hast du diese nur gelöscht?

Wäre doch interessant ob es dann mit einer anderen Schriftart besser funktioniert, bzw. was das Problem mit Source Sans Pro gewesen sein soll.

Zunächst: was da vom Seiten-Design (vergeßt ganz schnell Dinge wie „Webesiten-Programmierer“!) vorgegeben wird, sind Wünsche des Erstellers. Und Wünsche können, müssen aber nicht erfüllt werden!

Beispielsweise werden „hier“ in keinem Fall externe Schriften geladen: mir geht es um Inhalte. Wenn nur das Aussehen Grund sein soll, daß man sich „das“ ansieht, habe ich keinerlei Interesse. (Und das erwähnte Streichen vom „Programmierer“? JS läuft hier auch nur auf wenigen Seiten und unterliegt dabei auch noch der einen oder anderen Einschränkung!)

Dann kommt es natürlich auf den, nein, die Seiten-Quelltexte an. Da gibt es viele, sehr viele Möglichkeiten, etwas „falsch zu machen“. Falsch? Man kann da an vielen Ecken und Enden diskutieren. Mein „Lieblingsbeispiel“ in der Ecke: das von den „zuständigen Konsortien“ vorgegebene und erzwungene(!) „Web-Inhalte müssen auf allen Bildschirmen unbedingt falsch und unscharf dargestellt werden“! Sehr kurz gefaßte Begründung: 96dpi und tatsächlich gegebene Bildschirmauflösung haben in kaum einem Fall, womöglich in überhaupt keinem mehr, wenigstens ein ganzzahliges Teilungsverhältnis. Folge: Inhalte werden typischerweise zu klein, Bilder und Kanten „bunt“ dargestellt. Müssen so dargestellt werden! Sonst „ist der Browser kaputt“.)

Und, was mir hier zu Schriftarten gerade noch einfällt: eine (lokal vorhandene) Schriftart, welche in einem Browser (einer „Browser-Familie“, also über verschiedene Versionen hinweg) problemlos verwendet wird, ignoriert der andere, der aus einer anderen „Familie“ stammt. Die Frage wäre also: welche Browser machen da was genau falsch? Das Aussehen stimmt jedenfalls damit nicht mehr überein.

Nebenher ein Verweis auf einen schon älteren Text, der hiermit im Zusammenhang steht. (Nicht wundern: die Überschrift da wurde, m.Mn.n. in doch verfälschender Weise, geändert.)