Hallo zusammen,
Seit Office 2016 haben Word, Excel etc. in ihren Tiefen einen eigenen Schriftenordner mit Tonnen von Schriften die ich nicht brauche. Die müllen mir nur mein Schriftartenmenü zu.
Kennt jemand eine Möglichkeit diesem Problem Herr zu werden und die Schriften los zu werden? Einfach die Schriften in diesen Ordnern zu löschen funktioniert nicht, dann stürzt Word sofort ab.
Unter Windows gibt es wohl eine Möglichkeit: https://support.office.com/en-us/article/remove-languages-an d-fonts-you-don-t-use-0915efdf-3eec-4e87-8b2f-ba0d47242ea6
Aber der Link der dort für den Mac angegeben ist führt zu Apple und hilft hier nicht wirklich weil die Schriften der Schriftenverwaltung von Apple ja gar nicht bekannt sind (Früher gab es diesen Ordner "Office Schriften" in /Library/fonts. Aber jetzt kocht MS seine eigen Suppe und die schmeckt mir nicht.

kleines Update. Scheint nicht zu gehen: http://www.jklstudios.com/misc/osxfonts.html

Im Selbstversuch habe ich bis auf die Arial alles aus dem Fontordner entfernen können. Ohne Arial stürzt Word ab. Die Schriftenliste selber schein sich aber momentan nicht verkürzen zu lassen. Die ist scheint irgendwo harncodiert zu sein.
Lediglich die Schriftvorschauen wird man irgendwie los. Zumindest bei einem neuen Benutzer war die Vorschau nur noch bei den Schriften da, die auch wirklich vorhanden und oder im System eingeschaltet sind. Alle anderen werden im Menü mit dem normalen Zeichensatz dargestellt. Welchen Ordner man in seiner Library löschen muß damit man die Schriftprevies los wird hab ich noch nicht rausgefunden.

"Harncodiert" ist ein schöner Ausdruck - paßt zu MS

Fontcache geleert? Im Font Explorer gibts jedenfalls dafür eine Option für Word, um den Cache zu leeren.

Peter
beschwer dich bei Apple über deren Autokorrektur. Die hat nix als Blödsinn im Kopf. Auch wenn's diesmal irgendwie doch paßt
Ja, aber den gibt es nicht mehr beim Office 2016. Auch ein sicherer Systemstart hilf nicht.

Allerdings scheint es Word inzwischen kapiert zu haben. Keine Ahnung was genau ihm den Kick gegeben hat. Aktuell reagiert es aufs Wort wenn ich Schriften in im Package rein oder raus nehme. OK, im Moment ist bis auf die Arial jetzt alles raus und mit der kann ich in Word leben Jetzt ist mein Schriftartenmenü wieder schön übersichtlich. Ich hoffe, das bleibt so (bis zum nächsten Update von Office)

Und zur Info fürs Archiv. Ich kämpf(t)e mit der V16.15.

MikeMuc:

Font Management in macOS, by Kurt Lang (Last updated May 27, 2018) ,
insbesondere Abschnitt Fonts installed by Microsoft Office bzw. Fonts installed by Microsoft Office: Office 2016

Von Apple erlaubt und so vorgesehen, siehe:

Apple Developer: Adding a Custom Font to Your App (iOS)
Add a custom font to your app and use it in your app’s interface. :

Äquivalent unter macOS:

Apple Developer: macOS Keys: ATSApplicationFontsPath :

sierkb:
ja, deinen Link hab ich schon in der Frage gepostet Deshalb schrieb ich anfangs auch das es scheinbar nicht möglich ist beim aktuellen Office das Menü auszudünnen. Nachdem ich aber wie eine Furie in der App "rumgemacht" habe hat sich mein Word schon mal eines besseren besonnen.

Ferner mag Apple ja erlauben und gibt es so schon sein X10.0, nur was soll ich mit dem ganzen Mist. Ich brauch die Officeschriften nicht (nie) und MS bietet unter WIN ja sogar selber eine Option wie man die abschalten kann. Und 3 Apps die 3x den gleichen Schriftenordner huckepack tragen ist doch krank, es gibt Möglichkeiten, das besser zu machen. Und damit meine ich nicht, dass eine App gleich einengenden Sack Schriften mitbringt und dem User aufzwingt. Das muß abschaltbar sein ohne das man gleich unbundle rumpfuschen muß.

MikeMuc:

Stimmt, Du hast Recht. Nachgereicht in Deinem nachfolgenden Update-Post. Sorry, hatte ich bis zu Deinem jetzigen Hinweis übersehen. Entschuldigung.

Dann haste dort sicherlich auch das hier gelesen:

Bedanke Dich bei Apple.

Das mit der Sandbox ist vorgeschoben. Außerdem ist das, was MS da momentan fabriziert eigentlich ein Missbrauch. Die "App eigenen" Schriftordner sind dafür gedacht, das man einen speziellen Symbolfont etc einfach einbinden kann. Für solche Massen wie sie MS da unterbringt gibt es den Fontsordner in der Userlibrary. Alles andere ist Entmündigung des Käufers. Mit Apple hat das als mal rein gar nichts zu tuen.
Mittlerweile habe ich es ja in Word hinbekommen das alles außer der Arial raus ist. Beim Rest ist es mir ehrlich gesagt egal was da für Schriften drin sind. Eigentlich sogar bei Word aber das brauche ich gelegentlich, dann aber oft mit "Spezialschriften" die irgendwer selber gestrickt hat

Bei jamf habe ich mal gelesen, dass es die Richtlinien von Apple zur Distribution über den Mac App Store erforderlich machen, dass alle Ressourcen innerhalb des Programms vorgehalten werden müssen. Offenbar scheinen die Richtlinien von Apple auch vorzusehen, dass nach dem Kauf (und der Installation im Ordner Applications) nichts nachgeladen werden darf. Ich finde das zumindest in diesem Fall nicht praxisgerecht.

Das Thema mit den Fonts beim Office 2016 (und das schnarchige Verhalten beim Start der Programme) ist der Grund für mich, warum ich "beinhart" an Office 2011 festhalte (so lange es irgendwie noch geht).

Würde Office in einer "Basisversion" (ohne diese vielen Fonts) distribuiert werden, würde ich auch auf 2016 upgraden wollen. Was spricht denn dagegen, die "Basisversion" zu kaufen und dann als "Extra" das Fontpaket laden zu können (das ich dann wahlweise nur für einen User oder alle User installiere)?

Da spricht garnis gegen. Aber da es sich hier um das Office für den Mac handelt welches meines Wissens garnicht über den ApStore verkauft wird braucht man auch nicht auf dessen Richtlinien Rücksicht zu nehmen.
Preislich wird das Schriftenpaket kam ins Gewicht fallen, das sind doch eh alles von MS kopierte "eigene" Schriften. Also würde ein Ankreuzend beim Installer reichen ob man die Schriften installieren will oder nicht. Selbst das muß nicht sein wenn die Schriften da in kommen wo sie hingehören, in /Library/Fonts oder ~/Library/Fonts. Die Appeigenen Ordner sollten nicht für solche Pakete missbraucht werden, außer die App biet in den Voreinstellungen einen eigene Möglichkeit, diesen Mist Balast abzuschalten.

... dieses Problems Herr zu werden.

Wobei mich die Fragestellung auch interessiert.

Der Link zur Problemlösung wurde doch längst gepostet, siehe oben – Stichwort "Kurt Lang".

..ich würde mir so etwas in keinster Weise aufoktroyieren lassen!

Ich habe das eben nachgestellt. Es ist so, wie es @MikeMuc geschildert hat. Man wird die Seuche in den Menüeinträgen nicht los. Der Hund liegt wahrscheinlich im "MicrosoftFontLibrary.framework" begraben, da sind die ganzen Fonts gelistet, denen man Herr werden will. Empfehlung: Ältere Version laden:

Doch, mit genügend Mut und Wut im Bauch hab ich es geschafft. Nur konnte ich am Ende nicht mehr genau sagen welche Löschaktion in welchem Framework dann zum Erfolg geführt hat.
Um festzustellen wo und in welchen Dateien Fontnamen sind hab ich die Multifilesuche vom TextWrangler verwendet. Diese Dateien habe ich mir dann näher angeschaut und ggf die Zeichensätze darin entfernt
Wenn jemand ein gutes Tool kenn mit dem man 2 Programmfiles vergleichen kann dann grabe ich aus dem Backup das alte Word aus und poste, welche Dateien ich modifiziert habe.

/usr/bin/diff (diff - compare files line by line), Manpage: man diff
/usr/bin/cmp (cmp - compare two files byte by byte), Manpage: man cmp

Kompliment! Bin gespannt, wie du das gemacht hast und freue mich auf die Lösung!

sierkb:
Stelle dir vor, ich bin einem Ordner in dem die alte und die neue Programmdatei liegen. Was genau muß ich dann eingeben damit alle Dateien in denkenden Bundles verglichen werden? Ich kann das ja nicht für alle 20000 oder wieviele Dateien einzeln machen. Ich brauch wen der mich an die Hand nimmt

MikeMuc:

Ich bezog mich darauf

Welche Dateien/Ordner hast Du denn modifiziert? Kann ja nur eine überschaubare Anzahl sein, an die Du Hand angelegt hast und nicht 20000, oder?

Z.B. mit:

diff -u Datei1 Datei2 (bzgl. 2er Dateien)
diff -urq Order1 Order2 (bzgl. der in 2 Ordern enthaltenen Dateien bzw. der Orderstruktur)

Zudem: hast Du Xcode installiert? Das hat ein Tool an Bord, FileMerge, das das auch kann und ein GUI dazu hat, zu finden unter /Applications/Xcode.app/Contents/Applications/FileMerge.app

Wäre es da nicht im Erstansatz einfacher, nach dem unterschiedlichen Datum zu suchen, welches die letzte Bearbeitung der Dateien kennzeichnet? Und erst im zweiten Schritt dann die Suche nach unterschiedlichen Inhalten? Wenn das Datum der Veränderung heute ist, findet man das doch schon mit einem Tool wie EasyFind ganz easy, oder?

So, ha mal mit TextWrangler nach Bauhaus in allen Dateien gesucht.
Bei den Frameworks hat diese Datei Federn gelassen: WordNEU/Contents/Frameworks/WLMGraphicsDevice.framework/Vers ions/A/Resources/FamilyNames.plist
Dort hab ich aber lediglich den Abschnitt zur Bauhaus entfernt. Ich wollte halt mal schauen was dann passiert (erst nix, war aber die letzte Aktion und kurz darauf war das Menü geschrumpft
Im Resourcenordner hab ich der Datei applicationfontmetadata.json lediglich ein Minus davor verpasst. Hat niemanden gestört, wird wohl nicht verwendet... Drin geändert hab ich daher nix
Aktuell sind im Fontsordner nur noch diese Schriften:
arial.ttf
arialbd.ttf
arialbi.ttf
ariali.ttf
MS Reference Sans Serif.ttf
MS Reference Specialty.ttf
Ohne die Arial stürzt Word gleich ab. Ob es alle braucht oder nur eine hab ich nicht weiter getestet.

In der Datei DWriteFontInfo.plist hab ich im ersten Array "MSBundledFontsPostscriptNames" alle Schriften entfernt, das ist jetzt leer

Die Dateien
fontsGDIFamilyNames.plist
fontsInfo.plist
hab ich ersatzlos gelöscht. Stört sich anscheinend niemand dran Word startet noch.

So, jetzt dürfen die mutigen unter euch selber ran und probieren. Vielleicht muß man auch mal einen sicheren Systemstart dazwischen schieben.
Ich warte auf eure Erfahrungen

Komme ich erst morgen zu! Auf jeden Fall schon mal vielen Dank für deine Pionierabeit! Dieses ellenlange Fontmenü ist einfach nur ätzend.

Ja, ätzender geht es wirklich nicht.
Alles muß man selber machen wen man es so haben will wie man es braucht

Funzt! Ich habe das eben in einer VM ausprobiert. Es muss lediglich die "applicationfontmetadata.json" umbenannt werden. Bei Word muss die Arial drin bleiben, der Rest kann weg. Bei PowerPoint und Excel auch die "applicationfontmetadata.json" umbenennen, es können jedoch alle Fonts gelöscht werden. Ich habe einfach den kompletten Ordner "Fonts" in die Tonne gezogen.

Bemerkenswert: Die Programme starten jetzt fast so schnell wie das Office 2011. Wenn ich jetzt noch diese alberne WYSIWYG Darstellung im Fontmenü abstellen könnte, würden die 2016er Programme wahrscheinlich noch schneller starten. Weiss jemand wie das geht?

Auf jeden Fall Tausend Dank, MikeMuc!

Randbemerkung: Eine Suche mit Google nach "applicationfontmetadata.json" (incl. der Anführungen) liefert Stand heute exakt NULL TREFFER !!!!!!
Das bedeutet: MikeMuc und das Forum haben Weltpremiere, was diesen Hack betrifft.

Hier der Beweis:

Welcher Vollpfosten ist ein mit -1 unterwegs. Ich hatte allerdings nicht den Eindruck das die applicationfontmetadata.json die alleinige Lösung ist. Die hatte ich, glaube ich, zuerst umbenannt.
Aber wenn das wirklich alles ist dann ist ds super. Sollte das noch jemand bestätigen dann können wir da ja bei Kurt Lang als Lösung einreichen. So von wegen geht nicht gibts nicht

Ich habe es mal probiert, wie ich es verstanden habe:
ich habe Exxcel + Word 2016 installiert, bin in die Pakete gegangen, habe dort in Resources die Datei applicationfontmetadata.json umbenannt, die Zeichensätze aus den Paketen gelöscht (bis auf Arial in Word).
Dann habe ich sicherheitshalber die Zeichensatz-Caches neu aufgebaut.
Die MS-Zeichensätze sind aus den Font-Menues verschwunden, beide Programme funktionieren noch.
Es scheint also zu gehen, mal sehen was das nächste Update sagt.

MikeMuc, ratz-fatz: Danke für die für die Lösung .

bmonno
Danke auch dir fürs Testen. Wir haben die Lösung mittlerweile bei Kurt vorgestellt. Er wird es dort in Kürze dann als Lösung offiziell in sein Blog mit aufnehmen.

MikeMuc:

Glückwunsch. Ich will Deine/eure Freude ja ungern trüben, aber:

Was sagt denn eigentlich macOS' eingebautes Code Signing Checking, im Zusammenspiel mit Gatekeeper und der Sandbox dazu, dass nach Deiner/eurer Veränderung/Manipulation am App-Bundle ja die mitgelieferte Bundle-Signatur bzw. der Hash nun nicht mehr stimmt, und wie wird es diesbzgl. aussehen, wenn Apple ab kommendem macOS Mojave Release die Zügel noch straffer zieht bzw. Whitelisting einführt (mindestens für Non-App Store-Apps), um manipulierte Apps (und genau das ist ja das, was Du/ihr macht: das App-Bundle manipulieren und verändern) noch besser vom System fernzuhalten und ggf. am Starten/Ausführen zu hindern?

Bisher läuft's bei euch, gefühlt, vermeintlich und augenscheinlich – weil evtl. Glück gehabt? Bei anderen, mit evtl anderer und ggf. strengerer Konfiguration (z.B. bzgl. Gatekeeper) auch? Und in Zukunft bzw. nach einem der nächsten System-Updates, Office-Fix-/-Update oder gar Mojave-Upgrade? Dann auch noch? Hast Du, habt ihr das auch bedacht und ausgiebig in unterschiedlicher Konfiguration gestestet?
*nachdenk*

Guter Punkt. Anderes rum gefragt: Wie praktikabel wird in Zukunft noch die Anwendung eines Tools zur Entfernung überflüssiger Sprach-Ressourcen sein (Monolingual), das ja im Prinzip auch nichts anderes macht, als in die "Bundles einzugreifen" und damit dafür sorgt, dass eigentlich alle von dir erwähnten Sicherheitsmaßnahmen des Systems Alarm schlagen?

Der "Hack" von MikeMuc ist wie der Name schon sagt – ein Hack. Das ist nix für den zart besaiteten 0815 User und den viel beschworenen Massenmarkt. Es sind sicherlich 98% der Anwender mit der Font-Situation von MS zufrieden. Die paar "Fanatiker", denen ein cleaner Look des Fontmenüs wichtig ist (dazu möchte ich mich gerne zählen), nehmen eventuelle "Nachteile" gerne in Kauf. Zumal die ursprüngliche Situation ja mit ein paar Mausklicks wieder hergestellt werden kann.

Dennoch ist das von dir beschriebene Szenario vollkommen richtig. Ich werde ab sofort stärker die Entwicklung von Monolingual im Auge behalten (es gibt dort noch keine Beta für Mojave), weil die dort sicherlich zuerst mit den Problemen konfrontiert werden, die du hier beschrieben hast. Oder ist das Entfernen der Sprach-Ressourcen ein Vorgang, der die von dir erwähnten Checks grundsätzlich nicht triggert?

sierkb
Tja, da hast du Recht. Das könnte uns an den Karren fahren. Wobei ich mir vorstellen könnte das ein einfaches umbenennen einer Datei auf das Signing weniger bis gar keinen Einfluß hat. Ebenso das Entfernen von Dateien. Erst wenn Prüfsummen „über alle Dateien“ ins Spiel kommen kann es kritisch werden.
Aber soweit wollen wir gar nicht schauen. Vorher wird uns sicher MS mit dem nächsten Update ärgern
Mit solchen Hacks kam man sich eh nur am hier und jetzt orientieren. Und da funktioniert es gerade

Nice: