Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03280.jsonl.gz/743

ein Aspekt, der gerne untergeht: zunächst mal sind Fonts komplett Plattform-agnostisch. Ein Type 1-Font oder ein TrueType-Font hat mit keiner Plattform irgendetwas zu tun. Fonts werden ja auch in den unterschiedlichsten Zusammenhängen eingesetzt: in Druckern/Ausgabesystemen, auf (natürlich plattform-spezifischen) Rechnern, als 'private' Fontbereiche von Applikationen (z.B. Adobe-Programme) usw.
Letztlich muss ein Font aber auf dem verwendeten System (oder in einer Datei, wenn er dort eingebettet ist) in einer bestimmten Weise als eine Folge von Bytes kodiert sein, und er muss sich an Konventionen und Spielregeln auf der betreffenden Plattform halten.
Hier kommen nun in der Tat Plattform-Unterschiede zum Tragen (die allerdings dabei sind, weniger zu werden): - auf Mac OS 9 und früher braucht(e) man zusätzlich zum eigentlichen Font noch einen Bildschirmfont (nur bei Type 1) sowie zusätzliche Info über den Font; bei Type 1-Fonts war dies in einer eigenen Datei untergebracht, bei TrueType war das mit dem eigentlichen Font in derselben Datei untergebracht (die auch mehrere TrueType-Fonts auf einmal enthalten kann, z.B. für normalen, kursiven und fetten Schriftschnitt - die Printer-Fonts für Type 1 auf Mac OS 9 hingegen enthalten immer nur einen Schnitt, wohingegen der Screen-Font Infos für mehrere Type 1-Printer-Fonts enthalten kann) - auf Unix/Linux/X11-Umgebungen oder z.B. für TeX-Umgebungen gelten wieder ganz andere Spielregeln - Windows unterstützt eigentlich keine Type 1-Fonts und erfordert ATM; hier findet man dann .PFB-Dateien (printer font binary - enthält den eigentlichen Font) und .AFM-Dateien bzw. .PFM-Dateien (Adobe Font Metrics/Printer Font Metrics - enthält u.a. Infos zu den Zeichenbreiten); TrueType-Fonts hingegen 'leben' in einer Datei mit der Endung .TTF (TrueType font); eine .TTC-Datei kann mehrere TrueType-Fonts auf einmal enthalten (TrueType collection) - Mac OS X kann inzwischen .TTF oder .TTC wie auf Windows üblich genausogut verwenden wie nach klassischer Mac OS 9 Manier kodierte TrueType-Fonts (Windows hingegen kann mit Mac OS 9 kodierten TrueType-Fonts bzw. PostScript Type Screen/Printer-Fonst nichts anfangen, was aber 'nur' am Mac-spezifischen zweiteiligen Dateiformat - mit Data Fork und Resource Fork - liegt) - OpenType-Fonts entspannen die Lage noch weitergehend: sie können ohne weiteres auf Mac und Windows eingesetzt werden, aber: es gibt zwei Varianten von OpenType: TrueType-basierend und Type 1-basierend. Der Support für letztere ist auf Windows nicht gegeben. ABER: - wenn man z.B. Adobe's Creative Suite einsetzt, wird OpenType/Type 1 ohne wenn und aber auch auf Windows unterstützt.
Übrigens: - wenn man mit der Creative Suite arbeitet (gilt wahrscheinlich auch für QuarkXPress 7, weiss ich aber nicht genau...), würde man heutzutage einfach OpenType-Fonts kaufen (Plattform per definitionem egal) - wenn man TrueType-Fonts kauft und mit Mac OS X und/oder Windows arbeitet, kauft man die PC-Version des TrueType-Fonts - wenn man mit Mac OS 9 arbeitet, sollte man sowieso schleunigst auf Mac OS X updaten - wenn man Type 1-Fonts kauft/kaufen muss, nimmt man die Plattform, auf der man arbeitet (es gibt Konverter von Mac nach PC und umgekehrt; wenn man beim Konvertieren nicht auch noch von Type 1 nach TrueType oder umgekehrt konvertiert sonder z.B. von Type 1/Mac nach Type 1/Windows, ist das Risko gering dass etwas schief geht - es bleibt letztlich derselbe Font, nur ander eingepackt; eine Konvertierung von Type 1 nach TrueType oder umgekehrt kann gut funktionieren, muss aber nicht, und im Problemfall ist dies nicht unbedingt die Schuld des Konvertierungsprogramms, sondern kann einfach am betreffenden Font liegen).
beschriebene Problem, habe ich eben beschlossen, meinen Fix fürs Problem zu veröffentlichen (weil ich alle Hoffnung fahren gelassen habe, daß Quark da was Vernünftiges rausbringen wird -- siehe weiter unten)
* Drei klitzekleine CUPS-Backends installieren, die für Distiller 6, 7 und 8 zuständig sind (wenn die entsprechende Distiller-Version nicht auf dem Mac aktiv sind, bleibt das Backend inaktiv)
* Wenn ein "Distiller-Drucker" bereits eingerichtet ist, für diesen einen neuen gleichlautenden Drucker anlegen, der noch die Ergänzung "(Xpress 7.x Distiller-Fix") im Namen trägt. Es wird auch die selbe PPD genutzt wie für den korrespondierenden Distiller-Drucker
Das Ganze sieht dann anschl. bspw. so aus wie in beigefügtem Screenshot.
Was hat man anschließend? Die Möglichkeit, wieder direkt aus Xpress 7.x heraus "direkt in den Distiller" zu drucken, indem man die gefixten Varianten benutzt (Handhabung 1:1 wie beim originalen Adobe-PDF-Drucker: D.h. Joboptions im Druckdialog auswählen, dito Speicherort des PDF -- wenn hier was nicht klappt, dann ist eine falsche PPD ausgewählt worden).
Was geschieht dabei im Hintergrund? Xpress erzeugt wie gehabt eine temporäre Datei, schiebt die ins Drucksystem und mein Backend wird dann mit dem Pfad zu dieser Datei aufgerufen. Mein Backend verschiebt dann die temporäre Datei an eine sichere Stelle, ruft Adobes Backend auf und fertig.
Wer sollte das Ganze einsetzen? Eigentlich jeder, der direkt den Distiller aus Xpress heraus nutzen will (zu den Risiken und Nebenwirkungen des Ganzen hinsichtlich "PDF-Boxen" gibt es ja geteilte Meinungen) und nicht auf den "offiziellen Fix" seitens Quark warten will. Ich will das definitiv nicht mehr, denn abgesehen davon, daß der eh erst mit Xpress 7.3 funktionieren kann, so wie es Quark aktuell vorhat, bemüht sich Quarks Lösung redlich alle Nachteile der beiden in
skizzierten Ansätze zu vereinigen (also ab 7.3 wieder PS-Datei mit anderem MIME-Type spoolen und diesen dann von einem Mini-CUPS-Filter einlesen und an "standard out" Richtung Adobe Distiller duplizieren).
Warum Quark das Problem mit 7.3 nicht einfach aus der Welt schafft, wenn sie eh nur vorhaben, einen Fix anzubieten, der ab 7.3 funktioniert, will mir zwar nicht in den Kopf. Ist mir inzwischen aber auch egal, da ich dem Spielchen "Gratis-Consulting Richtung Quark" nicht mehr allzu viel abgewinnen kann.
Obige Lösung funktioniert jedenfalls mit jeder Xpress 7.x Version und ohne Performance-Einbußen wie die Quarksche. Dafür halt mit dem ästhetischen Makel, daß je installiertem "AdobePDF"-Drucker noch eine zusätzliche Queue im Druckdialog auftaucht (diese kann aber aus jeder Anwendung heraus und nicht nur Xpress genutzt werden)
Frage zur Bearbeitung eines PDFs mit Callas pdfCorrect
UCR und Schwarzaufbau wirken sich nur aus, wenn es DeviceRGB im PDF gibt. Sie definieren Parameter fuer die Umrechnung von RGB nach CMYK. In der Praxis macht das fast niemand mehr. Alle professionellen Tools und Systeme verwenden statt dessen ICC-basierte Umrechnungen (und bei DeviceRGB wird halt ein default-RGB-Profil eingestellt bzw. angenommen).
Da in einem PDF/X-1a oder einem PDF/X-3 mit CMYK-Zielprofil sowieso kein DeviceRGB vorkommen darf, spielen diese beiden Parameter sowieso keine Rolle. Sie sind letztlich Ueberbleibsel aus einer PostScript-Zeit vor der Einfuehrung CIE-basierten Farbmanagements.