Umlautzeichen in der ITC Officina Sans und Word 2010

[The-Too-Much-Coffee-Man]

Liebes Typografie-Forum,
ich bin relativ neu hier, habe mich aber nicht wegen meines Problems angemeldet. Ich hoffe, dass ich hier überhaupt ansatzweise richtig bin, falls nicht, bitte ich um Nachsicht. 

Wir verwenden als Hausschrift die ITC Officina. Ich möchte in Word 2010 (Windows 7) ein Dokument damit setzen, einige der Daten stammen aus Excel 2010. Wenn ich diese Daten in Word 2010 kopiere, erscheinen die Minuskeln der Umlaute in falscher Darstellung: die Umlautzeichen werden rechts neben dem Vokal als Trema über einem Spatium dargestellt. Ich kann das Problem reproduzieren, allerdings nur mit dieser Schrift (umgewandelt in jede andere funktionieren die Umlaute) und auch nur in Word. Wende ich die Officina in Excel auf den gleichen Text an, stimmt ebenfalls alles.
Mir ist das rätselhaft und ich kann leider auch keine Lösung oder wenigstens einen Ansatz im Netz finden. Das Problem mit den verschobenen Umlautzeichen haben einige, aber meist kommt es im Webdesign vor. Als schlichtes Problem mit einer WYSIWYG-Office-Anwendung hatte das scheinbar noch niemand.
Hier mal zwei Beispiele:  
https://www.dropbox.com/s/9qy5m06krxnn25v/Bsp. 1 Officina.JPG?dl=0
https://www.dropbox.com/s/r0cycz7ylxjcwtk/Bsp. 2 Officina.JPG?dl=0

Falls ich hier absolut falsch bin, verzeiht. Falls nicht, freue ich mich über jede Hilfe.
Vielen Dank und viele Grüße,
Christian Schmidt
 

[Gast bertel]

Verwendest du einen PostScript-Font? Dann lies mal hier: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_word-mso_other-mso_2010/word-2010-problem-with-postscript-type-1-fonts-and/a2ed8933-6a31-4371-82fc-1fa56c81d22e

[catfonts]

Hallo Christian, willkommen hier!

Und ja, du bis hier richtig, denn auch solvje Sachen gehören zu unseren Themen hier.

 

Und darum gleich zum Thema:

Mir kommt es so vor, als ob in deinem Problem-Dokumenten  nicht wirklich ä, ö und ü sondern tatsächlich a, o, u + ¨ hinterlegt ist, bei welchem ¨ eben als Combining Diaeresis (uni+0308) eigentlich von den anderen Programmen über den Buchstaben geschoben werden, in Word aber leider nicht.

 

Rettung sollte einn Suchen und Ersetzen-Durchlauf  sein, bei dem du  a¨ o¨ und u¨ durch ä, ö und ü ersetzt

[The-Too-Much-Coffee-Man]

Vielen Dank euch beiden, das ging ja ratzfatz.
Zu PostScript, lieber @bertel - das muss ich erstmal rausfinden, klingt aber interessant. Das schaue ich mir an.
Zum Vorschlag mit Suchen&Ersetzen, das hatte ich auch schon irgendwo gelesen aber es klappt nicht. Allein schon, wenn ich  a¨ o¨ oder u¨ aus dem Text kopieren möchte, um es ins Suchen&Ersetzen-Feld einzutragen, kommt dort nur der korrekte Umlaut an. Wenn ich a¨ o¨ und u¨ händisch dort eingebe, findet er sie nicht ("keine Übereinstimmungen"). 
Einfach alle Umlaute durch sich selbst zu ersetzen, um korrekt dargestellte Umlaute zu erhalten, funktioniert auch nicht. Die ersetzten Umlaute (die er dann zumindest auch findet) sehen genauso aus, wie vorher.
Es spricht also einiges dafür, dass es bei meinem Problem tatsächlich falsch angezeigte Umlaute sind.
Dennoch: nochmals danke für den Input.

[catfonts]

Trotzdem mal probiert, ob das Suchen und Ersetzen was bringt, auch wenn das kopierte a¨ im Suchen-Eingabefeld korrekt wie ä dargestellt wird?  sonst vielleicht nur erst das ¨ durch ein anderes, im Text nicht vorhandenes Zeichen, z.B. § ersetzen, und dann a§ durch ä

?

[Þorsten]

vor einer Stunde schrieb The-Too-Much-Coffee-Man:

wenn ich  a¨ o¨ oder u¨ aus dem Text kopieren möchte, um es ins Suchen&Ersetzen-Feld einzutragen, kommt dort nur der korrekte Umlaut an

Das weiß man nicht. Siehe dieses Bild, das aus der folgenden URL erzeugt wird:

http://type.dt1.org/render/EB Garamond/äö.png

Das ist ein richtiges ä, ein normales o und ein kombinierendes Trema ◌̈

 

In den meisten Browser-Font-Kombinationen werden die beiden letzten Zeichen korrekt zu einem ö kombiniert. Die Software, die das Schriftmuster erzeugt, kann das allerdings nicht und so steht das Trema dort fälschlicherweise allein hinter dem o.

[The-Too-Much-Coffee-Man]

Interessant. Beides. Danke @catfonts, danke @Þorsten. Ich werde mir das ab Montag auf der Arbeit nochmal in Ruhe ansehen, der fragliche Text und die Schrift sind auf dem Bürorechner. Ich halte euch auf dem Laufenden über meine Fortschritte. Schönes Wochenende an alle Beteiligten!

[mangomix]

Betrifft es nur die Daten aus Excel, d.h. wenn du in anderen Word-Dokumenten in ITC Officina schreibst, "passen" auch die Umlaut-Kleinbuchstaben? Und wie kamen die Daten von Excel nach Word? Normales Copy & Paste inkl. Formatierung? Macht es einen Unterschied, wenn du mal testweise einfügst mit Start > Einfügen >Inhalte einfügen > Unformatierten Text sowie mit Start > Einfügen >Inhalte einfügen > Unformatierten Unicode-Text?

 

Die Probleme neurerer Word-Versionen im Umgang mit Postscript Type 1 Fonts, auf die Bertel hinwies, kenne ich auch ... jedoch mit anderen Symptomen (da ist die Darstellung völlig im Eimer). Interessant ist jedenfalls, dass das nicht programmübergreifend auftritt. Habe einige installierte Type 1 Fonts, die in MS Word nicht mehr tun, im MS Publisher der gleichen Office-"Genereation" aber sehr wohl noch.

[The-Too-Much-Coffee-Man]

Hallo Mangomix,
danke auch für Deinen Beitrag.
Ich habe es gerade einmal ausprobiert. Sowohl mit Start > Einfügen >Inhalte einfügen > Unformatierten Text als auch mit Start > Einfügen >Inhalte einfügen > Unformatierten Unicode-Text reproduziere ich das Problem, d.h. die Umlaut sind nicht korrekt dargestellt. 

Nachdem ich im Kollegium eine kleine Umfrage gemacht habe, könnte ich mir auch vorstellen, dass es das beschriebene Post-Script-Problem ist, denn die meisten Kollegen hatten ein solches Problem noch nie, aber auf einem Rechner passiert mir der Schrift wohl genau das, was Du beschreibst: alles ist verpixelt und zerschossen. Nicht nur die Umlaute.

@catfonts: die Suchen&Ersetzen-Variante funktioniert leider nicht, weil das Trema in meinem Text nicht separat existiert. Ich kann es quasi nicht apart durch ein anderes Zeichen ersetzen. Falls ich Dich nicht komplett falsch verstanden habe.

Wie immer: danke an alle.
Beste Grüße,
Christian

 

[KlausWehling]

In 2020 läuft der Support für Windows 7 endgültig aus. Sollte also angedacht sein, in absehbarer Zeit auf Windows 10 umzusteigen, ist es erforderlich, alle Type-1 Schriften auf TrueType oder OpenType umzustellen. Für die Etat-Planung ist zu bedenken, dass alle Schriften neu lizensiert werden müssen.

 

Beste Grüße

[RobertMichael]

vor 1 Stunde schrieb KlausWehling:

ist es erforderlich, alle Type-1 Schriften auf TrueType oder OpenType umzustellen.

unterstützt Win 10 generell keine T1 oder ist es über einen Fontmanager (z.B. Fontexpert) möglich?

[The-Too-Much-Coffee-Man]

 Ein kurzer Zwischenstand. Ich habe herausgefunden, dass es sich bei der ITF Officina tatsächlich um eine PostScript-Schrift handelt . Allerdings habe ich das Problem auch in weiteren installierten Schriften (ich bin sie  anhand eines falsch dargestellten Zeichens einfach mal durchgegangen), und da sind auch TrueType-Schriften dabei. 
Überdies interessant: nicht immer steht bei diesem Fehler ein Trema vollständig neben dem Vokal, manchmal werden die Punkte auch nur zur Hälfte nach rechts verschoben. Und bei Symbol-Schriftarten oder bei Hebräisch ("Narkisim") steht sinnloserweise ebenfalls ein Trema rechts daneben oder halb über dem Buchstaben.  Wenn ich stattdessen einen funktionierendenUmlaut, der normal angezeigt wird, auf eine solche Schriftart umstelle, wird dieser dann einfach nicht ersetzt, sondern bleibt als Umlaut stehen.
Auch ist mir aufgefallen, dass in meinem gesamten Text einige Umlaute durchaus korrekt angezeigt werden (gleiche Schriftart, gleiche Übertragung des Inhalts ohne Formatierung). Und andere eben nicht. 
 

[mangomix]

vor 4 Stunden schrieb RobertMichael:

unterstützt Win 10 generell keine T1 oder ist es über einen Fontmanager (z.B. Fontexpert) möglich?

Soweit ich das verstanden habe, ist das kein Problem von Windows, sondern Office-immanent. Ich kann unter Win 10 problemlos TrueType 1-Schriften installieren und sie funktionieren auch in Anwendungen wie Scribus oder MS Publisher 2016. Probleme macht nur MS Office: Word verhunzt sie total, in PowerPoint werden sie ersetzt, in Excel gar nicht auf der Font-Liste angezeigt.

 

@The-Too-Much-Coffee-Man: Ich würde die Ursache des Problems dann irgendwo im Umfeld von Unicode und inkompatiblen Zeichencodierungen auf deinem Rechner vermuten. Wohlgemerkt nur vermuten ... da bin ich kein Experte. Ich drücke die Daumen - und hoffe, dass du dir diese wunderhübsche Trost-Karte nicht bestellen musst: http://www.blog.druckerey.de/index.php?id=695

[Þorsten]

vor 3 Stunden schrieb The-Too-Much-Coffee-Man:

Allerdings habe ich das Problem auch in weiteren installierten Schriften (ich bin sie  anhand eines falsch dargestellten Zeichens einfach mal durchgegangen), und da sind auch TrueType-Schriften dabei.

Was passiert, wenn du in einem neuen Dokument die Schriftart auf eine der problematischen Schriften umstellst und einfach Ä, ö, ü etc. eintippst? (Einfach um auszuschließen, dass du mit falsch kodierten Texten arbeitest.)

[The-Too-Much-Coffee-Man]

vor 15 Minuten schrieb Þorsten:

Was passiert, wenn du in einem neuen Dokument die Schriftart auf eine der problematischen Schriften umstellst und einfach Ä, ö, ü etc. eintippst? 

Die per Hand eingegebenen Buchstaben werden korrekt dargestellt.

[Þorsten]

Prima. Das hilft bei der Fehlersuche und bestätigt unsere Theorie, dass es sich um irgendein Encoding-Problem handelt.

 

Nächster Versuch: versuche, so viele Schritte des Ablaufs nachzuvollziehen. Z.B.: erstelle ein neues Dokument in Excel, tippe dort Umlaute ein, speichere es, kopieren die Daten in ein Word-Dokument. Auch dann alles OK?

 

Kannst du vielleicht ein Beispieldokument, in dem der Fehler auftritt, mit (einigen von) uns hier teilen? (Du kannst ja alle betriebswichtigen Infos löschen und nur ein oder zwei Wörter stehen lassen, in denen die auseinander dividierten Umlaute vorkommen.)

[catfonts]

Irgendwie habe ich noch immer den Verdacht, dass die sich zerlegemden Umlaute eigentlich gar keine sind, und die Urfassung dieses Dokuments aus einer Software kommt, welche die Umlaute aus Buchstabe + Trema komponiert, z.B. LaTeX als /"u eingegeben wurde.

 

Hast du bei der Suchen und Ersetzen-Funktion auch wirklich mal zerlegtes ü (also aus dem Dokument kopiert, und in der Suchmaaske als echtes ü sichtbar) durch in die Ersetz-Maske von Hand eingetippes ü ersetzt?

[The-Too-Much-Coffee-Man]

Zunächst @catfonts: Du scheinst recht zu haben. Ich habe die Suchen&Ersetzen-Funktion nochmal auf die von Dir beschriebene Weise durchgeführt. Jetzt ersetzt es mir die falschen Umlaute mit richtigen. Und nicht nur das. Wenn ich mit Backspace den einkopierten Umlaut aus der Suchmaske löschen will, löscht er nach 1x Backspace die Umlautpünktchen, also das Trema und es bleibt ein u oder a stehen. Beim zweiten Backspace löscht er dann auch den Vokal. Also ist es DOCH ein komponierter Buchstabe aus Vokal und Trema.

Nun bin ich etwas verwirrt: entweder hatte ich S&E bisher gar nicht loslaufen lassen, weil ich in der Suchmaske nur den korrekt dargestellten Buchstaben gesehen habe oder es ging bisher nicht. Logisch wäre ersteres. Aber ich hatte ja auch schon folgendes geschrieben und das stimmt weiterhin:

Am 9.3.2018 um 15:55 schrieb The-Too-Much-Coffee-Man:

... wenn ich  a¨ o¨ oder u¨ aus dem Text kopieren möchte, um es ins Suchen&Ersetzen-Feld einzutragen, kommt dort nur der korrekte Umlaut an. Wenn ich a¨ o¨ und u¨ händisch dort eingebe, findet er sie nicht ("keine Übereinstimmungen"). 
Einfach alle Umlaute durch sich selbst zu ersetzen, um korrekt dargestellte Umlaute zu erhalten, funktioniert auch nicht. Die ersetzten Umlaute (die er dann zumindest auch findet) sehen genauso aus, wie vorher.

Mir fehlen wahrscheinlich die Grundkenntnisse, um das zu verstehen, aber wenn ein händisch eingegebenes u¨ oder a¨ nicht gefunden wird, mein eigenes u¨ oder a¨ aber in der Suchen&Ersetzen-Maske mit Backspace zerlegbar sind, aus was wird das dann zusammengesetzt?
Das ist doch spooky!

[Ralf Herrmann]

vor 13 Minuten schrieb The-Too-Much-Coffee-Man:

Mir fehlen wahrscheinlich die Grundkenntnisse, um das zu verstehen, aber wenn ein händisch eingegebenes u¨ oder a¨ nicht gefunden wird, mein eigenes u¨ oder a¨ aber in der Suchen&Ersetzen-Maske mit Backspace zerlegbar sind, aus was wird das dann zusammengesetzt?

Ich werfe die kopierte Zeichenkette gern Graphemica vor – das zeigt mir dann, was tatsächlich hinterlegt ist. http://graphemica.com

Es kann z.B. auch noch ein Unicode-Steuerzeichen zwischen beiden Teilen stecken. 

[The-Too-Much-Coffee-Man]

@Þorsten: Wenn ich Umlaute wie vorgeschlagen in Excel per Hand eingebe und dann in Word kopiere, dann sind und bleiben es hübsche, reguläre Umlaute. In jeder Schriftart.

ITC Officina, PostScript: 
MS Reference Sans Serif, TrueType: 
MT Extra, TrueType: 

[The-Too-Much-Coffee-Man]

@Ralf: Danke. Das Ergebnis ist eindeutig, würde ich sagen. Das bestätigt @catfonts' Vermutung. 

[catfonts]

vor einer Stunde schrieb The-Too-Much-Coffee-Man:

aber wenn ein händisch eingegebenes u¨ oder a¨ nicht gefunden wird, mein eigenes u¨ oder a¨ aber in der Suchen&Ersetzen-Maske mit Backspace zerlegbar sind, aus was wird das dann zusammengesetzt?
Das ist doch spooky!

Nur um es noch einmal klar zu stellen: es gibt praktisch 3 Versionen der diakritischen Zeichen:

 

1. Schon fertig als gemeinsame Glyphe für die einzelnen Sprachen mit den dort üblichen Zusammenstellungen, im Deutschen enen ä, ö und ü als fertige Buchstaben. Diese können im Font selbst als komplette Glyphe angelegt sein, also mit allen Konturen des Buchstaben, wie auch des genau positionieren diakritischen Zeichens, oder eben als Composed-Glyphe, welche den blanken Buchstaben und in diesem Falle das normale Zeichen "dieresis" nur referenziert und als Layer übereinander legt, welches die Dateigröße des Fonts verringert. Welche Version in einem Font verwendet wurde, sieht man in der Regel nicht.

 

2. die alleinstehenden diakritischen Zeichen mit einer internen Zeichenbreite, die man eben auch von Hand so eingeben kann. Diese sitzen dann zumeist, sind die nicht über Kerning über den Buchstaben verschonen eben neben dem Buchstaben zuvor. Normalerweise wird hier schon durch das Betriebssystem  das Diakritisxche Zeichen VOR einem Buchstaben eingegeben, dann die Version 1 quasi als Ligatur eingesetzt, z.B. eingabe von `e ergibt è, e` hingegen bleibt e`

 

3. die kombinierenden diakritischen Zeichen, darunter eben das kombinierende trema. Diese haben einen eigenen Unicode-Block und haben selbst keine hinterlegte Zeichenbreite, und werden in Systemem mit einer Compose-Funktion verwendet, hierdurch können dann über jeden Buchstaben auch diverse diakritische Zeichen gesetzt werden, und so eben auch ungewöhnliche Kombinationen erstellt werden, wie sie z.B. bei Formelzeichen benötigt werden, so z.B. Volumenstrom in der Strömungslehre benötigt ein V mit Punkt darüber, das gibt es als fertiges Zeichen nicht. Das Problem hier: Systeme, und Software, welche die Compose-Funktion nicht kennt, korrigiert gelegentlich Zeichen ohne Breite um eine duchschnittliche Zeichenbreite. Ich hatte dies Problem schon bei einer Symbolschrift, bei der ich mehrere Glyphen als Layer übereinander legen wollte, indem ich hier Zeichen ohne eigene Zeichenbreite verwendete. Gerade in Word rutschten diese dann aber auseinander, weil die fehlende Zeichenbreite hier als Fehler angesehen und korrigiert wird. Meine Losung war, diesen Zeichen eine minimale Breite zu geben, und entsprechend die Layer-Glyphen zu verschieben.

[KlausWehling]

vor 22 Stunden schrieb RobertMichael:

unterstützt Win 10 generell keine T1 oder ist es über einen Fontmanager (z.B. Fontexpert) möglich?

Jein. T1-Schriften lassen sich zwar installieren, funktionieren aber nicht z.B. in Office-Programmen. Je nach Schrift gibt es da entweder reinen Zeichensalat oder das Kerning ist verhauen etc. In InDesign oder Illustrator (CS4) funktionieren sie anscheinend - ich traue der Angelegenheit aber nicht. Meines Wissens gibt es kein Font-Tool, welches T1-Schriften unter Windows 10 systemweit funktionieren lässt.

 

Da eingangs erwähnt wurde, dass die Officina als Hausschrift eingesetzt wird, und nur in T1 vorliegt, ist zu planen, beim Umstieg auf W10 auch alle Schriften umzustellen.

 

Beste Grüße 

[Taurec]

Hallo zusammen,

 

ich hatte vor einiger Zeit ein ähnliches Problem:

Kundin liefert Texte in MS Word an, ich füge diese mittels Copy&Paste in Wordpress ein.

Alles sieht gut aus, bis ich in Firebug den Check mache, wie sich die Seiten auf verschiedenen Mobilgeräten verhält.

Hier stolpere ich über eben jenes Problem, aus dem Umlauten werden u¨ und dergleichen.

Nachdem ich diese Zeichen manuell austausche, sieht alles wie gewünscht aus.

Die Kundin hat bestimmt keine expliziten Formatierungen der Umlaute vorgenommen.

Sie benutzt Word nur um die Texte einzugeben, da war noch nicht mal was in Sachen Bold oder Underline formatiert.

 

Ich habe hier vielmehr  MS Word in Verdacht da irgendwas nicht sauber abzuspeichern. Denn die Word-Dateien in OpenOffice geöffnet und dann in Wordpress eingefügt sorgten auch dafür, dass die Umlaute einwandfrei übertragen wurden.

[catfonts]

Gut möglich, dass die OpenOffice-Entwickler bei der Erstellung dieses Try-and-Error-Word-Importfilters, der ja ohne Dokumentation des Word-Dateiformats dir Versuch und Irrum hingefummelt werden musste auch auf das Problem mit Compose-Akzentglyphen gestoßen sind, und diese gleich beim Import über eine versteckte Autokorrektur gleich durch die regulären Akzent-Buchstaben ersetzen, so es direse in Unicode definiert gibt, und diese in der Schrift enthalten sind.

 

Ich habe schon oft durch hin und her importieren zwischen MS Office und Open/Libreoffice Probleme recht mühelos beseitigen können