Habe schon mehrfach von dem Problem im Web gelesen aber noch keine
funktionierende Lösung dafür gefunden.
Habe einen Font bekommen, der als Unix-Datei (mit 0KB) angezeigt wird.
Schriftensammlung erkennt die Datei(en) nicht. Apfel i und neu zuweisen
funzt auch nicht.
Wer weiss Rat?
Verwende OSX Tiger
Habe einen Font bekommen, der als Unix-Datei (mit 0KB)
angezeigt wird.
*gääähn*… irgendwann lernt es auch der letzte Mac-Anwender… ^^
Mac-Dateien bestehen (meist) aus 2 Teilen: Dem Datenzweig und dem Resourcenzweig. Wenn ich eine Mac-Datei auf ein System übertrage, welches damit nicht klar kommt, fliegt der Resourcen-Zweig raus. Das ist bei vielen Dateien nicht weiter tragisch, bei Bildern ist im Resourcenzweig i.d.R. nur z.B. die Voransicht drin. Bei anderen Dateien ist das aber tödlich, da quasi alles im Resourcenzweig drin ist - wie bei Schriften…
Im Resourcenzweig steht auch drin, was für eine Art Datei das ist - fehlt das, macht OS X nicht selten - mangels Informationen - eine „Unixdatei“ draus…
ergo: du hast nur den unbrauchbaren Datenteil bekommen - der ist Müll. Nochmal schicken lassen - aber als Archiv, z.B. .sit, .hqx usw.
ergo: du hast nur den unbrauchbaren Datenteil bekommen - der
ist Müll. Nochmal schicken lassen - aber als Archiv, z.B.
.sit, .hqx usw.
Ich habs als ZIP bekommen. Wie kann das also sein?
Noch was …
falls der Font nicht OSX kompatibel sein sollte hätte es ja unter OS 9
funktionieren müssen, oder etwa nicht? Habs unter OS 9.2.2 (keine
Classicumgebung) entpackt - gleiches Problem: 0KB
Selbst wenns ein WindowsFont sein sollte müsste das anders ausschaun
und nicht „0“ KB anzeigen.
Also von wegen „gähn …“ du hast mir zwar theoretisch gesagt woran’s
liegt. Aber so wirklich verstehn tu ich’s noch nicht.
Ich habs als ZIP bekommen. Wie kann das also sein?
ZIP-Archive sind primär aus der Windows-Ecke kommend. Nur die „appleeigene“ Version kommt mit Mac-Dateien klar. Aber nochmal zur Aufklärung:
Klassische Mac-Schriften bestehen aus einem Schriftenkoffer (Bitmap) und ggf. einer Postscript-Datei für vektorisierte Daten. Beides besteht - intern - aus jeweils einem Daten- und einem Resourcenzweig. Wird nur der Datenteil weitergegeben, sind beide Teile jeweils Müll. Auf dem Mac sieht man IMMER alles als eine EINE Datei - die Aufteilung ist unsichtbar!
Mac-TrueType-Schriften sind auch solche Zwitter, daher können Windows-Rechner auch nichts damit anfangen.
Windows-TrueType-Dateien bestehen nur aus einer Datendatei und enden normalerweise auf .ttf - OSX kann damit inzwischen direkt umgehen.
OpenType-Fonts bestehen auch nur aus einer Datendatei und enden auf .otf - es ist eine moderne Version der Postscript-Schriften (1.), nur daß hier beide Teile (Bitmap- und Postscript-Teil) nicht mehr getrennt werden. (Naja, es gibt noch mehr Unterschiede, aber das ist hier irrelevant)
Apple hat für OSX seine eigene TrueType-Variante modernisiert und den Resourcenteil mit in den Datenteil gepackt - heraus kam .dfont
Je nach Schrifttyp ist also eine „Resourcenteil-sichere“ Verpackung nötig, damit die Schriften bei Übertragungen nicht geschrottet werden. Üblichweise verwendet man auf dem Mac dafür die Formate AppleDouble, MacBinary oder BinHex. Die meisten Mac-Programme verpacken solche Zwei-Teile-Dateien automatisch, ohne daß der User davon etwas mitbekommt (viele ftp-Programme, Email-Programme usw.). Das geläufige Stuffit-Format macht es ebenso - sowohl .sit also auch .sitx beachten Resourcenzweige.
Anders sieht es mit anderen Archivierungsprogrammen aus. Zip, TAR, GZIP, RAR usw. sind nicht von Hause aus dazu in der Lage. Die von Apple mit 10.3 und 10.4 gelieferten Packer beherrschen es aber (meist), Apple hat inzwischen diese freien Versionen entsprechend angepaßt.
Ein Archiv an sich garantiert also nicht, daß die enthaltenen Dateien auch i.O. sind! Das hat nichts mit OS9 oder OSX zu tun, sondern ausschließlich damit, ob die Quelle die Datei(en) richtig verpackt hat. Wenn das Archivierungsprogramm die Resourcenzweige nicht mit verpackt, kommt nur Datenschrott raus. Verwendet man zueinander inkompatible Versionen von z.B. zip oder tar - passiert das gleiche. Sicher geht man nur, wenn man die Dateien in die dafür vorgesehenen Formate verpackt: BinHex, AppleDouble oder MacBinary. Die kann man dann ggf. nachträglich noch komprimieren - dann auch als zip oder rar oder tgz.
Und zum „*gäähn*“: Die Problematik gibt es, seit es MacOS/HFS gibt… also seit 20 Jahren… ^^
Und zum „*gäähn*“: Die Problematik gibt es, seit es MacOS/HFS
gibt… also seit 20 Jahren… ^^
O.K., denke jetzt hab ich’s „geschnaggelt“ - Danke für die ausführliche
Beschreibung. Für mich war das Phänomen halt neu.
Gruss
Marco