Am Sonntag, den 16.01.2005, 21:47 +0100 schrieb Michelle Konzack: > Am 2005-01-16 21:12:12, schrieb Christian Schmidt: > > Hallo Michelle, > > > > Das führt aber zwangsläufig dazu, das Mac $USER alle par Monate neu > > > Festplatten kaufen müssen oder ? > > > > Du spinnst. > > Warum, wenn die Datein alle doppelt abgelegt werden... Warum kannst du nicht einfach mal die Luft anhalten, bis du etwas begriffen hast? Verdammichnochmal. Immer diese unsachlichen Kommentare... Ein HFS+ ist ein Dateisystem, welches mehrere Streams pro Datei unterstützt - in diesem Fall zwei. Ressourcefork und Datafork. Diese Struktur dient nur dazu, Daten *logisch zu trennen*. Die Daten werden dadurch nicht "mehr". Beispiel: Wenn man aus einem Programm ein EPS abspeichert, wird zum Zwecke der schnellen Verarbeitung der Datei eine kleine Vorschau mit in die Datei geschrieben. Mach dir ein "PC-EPS" in einem geeigneten Tool auf (Hexeditor), und du erkennst hinter dem Postscriptcode, ganz am Ende, etwas, was ganz und gar nicht nach PostScript aussieht. Daß ist ein Pixelbild mit der Vorschau. Das erzeugende Programm muß natürlich Previews unterstützen, sonst isses witzlos. Sprich: Plattenplatz = eps-Code + Vorschau in *einer* Datei. Die gleiche Datei, von Mac-Software erzeugt, packt des eps in die Data-Fork, das Preview in die Ressourcefork. Sprich: Plattenplatz = eps-Code in Data + Vorschau in Ressource. Zusammen in beiden Fällen gleich viel. Nagel mich nicht auf ein Bit fest, aber es ist etwa gleich viel. Wenn der Mac Daten auf einem Filesystem ablegt, welches nicht fähig ist, "Forks" oder "Streams" zu verwenden, werden beide Forks einfach in zwei flachen Dateien abgelegt. Aber auch hier gilt: Plattenplatz = eps-Code in Data-Datei + Vorschau in Ressource-Datei. In der Regel ist das so gehalten, daß beim umkopieren die unsichtbaren Ressource-Forks (Das ist die Datei mit dem "._") nicht mitgenommen werden - diese Daten gehen verloren, und das ist auch gewollt, denn darin stehen die nicht-portablen, Mac-proprietären Infos. Im Falle des obigen eps'es eine Vorschau im "pict"-Format, mit der kaum ein anderes System was anfangen kann. Das Problem mit riesen Ressourcen ist etwas, was unter bestimmten Umständen auftreten kann - es ist dann aber auf ALLEN Systemen vorhanden, es wird nur nicht sichtbar, weil man dort die beiden Forks nicht getrennt betrachten kann. Beispiel: Ich erstelle in einem DTP-Programm ein leeres Dokument in der Größe von 1x1 Meter. Dann zeichne ich eine Linie quer durchs Bild und speichere das ganze als eps. Der Postscriptcode ist dann nur ein paar Bytes lang, irgendwas mit "line(x1,y1,x2,y2)". Dann wird an die Datei ein Preview drangeklebt - und das ist, trotz der geringen Auflösung von 72 oder 96 dpi eben immer noch einen ganzen Quadratmeter groß. Egal ob Mac-Pict-Ressource, oder plattes Dosen-Tif, in der Datei steht ein kompletter Quadratmeter Previewbild. Das ist beileibe kein alltägliches Problem, aber es kommt vor. Abhilfe schafft es z.B., die Größe des Bildes zugunsten der Auflösung umzurechnen. Wohlgemerkt, *umrechnen*. Das bedeutet nicht, daß man das Bild konvertiert, sondern nur, daß die gleiche Menge Pixel anders angegeben wird. In Photoshop geht das im Dialog "Bildgröße". Statt eines 100x100cm-Bild in 72dpi kann man z.B. ein 10x10cm-Bild in 720dpi verwenden (die Zahlen sind falsch, man braucht eine Quadratwurzel, aber ich erkläre nur das Prinzip). Dazu wird nicht mal was umgerechnet, die Daten bleiben unverändert, aber das Preview ist nur noch 10x10cm groß statt 1x1 Meter. Wahrscheinlich ist im vorliegenden Fall mit den JPGs etwas vergleichbares passiert. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil