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/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
