Liebe Experten,

wir sind gerade dabei den Create-PDF-Server von Helios zu testen und haben Acrobat 6 auf einer Doppelprozessor-Windows-Maschine installiert und als Create-PDF-Server eingerichtet. Das funktioniert prinzipiell auch sehr gut und schnell - wenn da das Problem mit der Helvetica nicht wäre ...

Wir beschicken den PDF-Server mit Dokumenten aus Quark, InDesign, Freehand und Illustrator von MacOSX-Rechnern aus.

Leider schreibt der Server keine PDFs von Quark und Freehand-Dateien, weil im Drucker-Log unter EtherShare-Admin angezeigt wird, das die Helvetica fehlt. Hmmmm, wir haben allerdings die OSX-System-Helvetica auf den entsprechenden Rechnern installiert und schicken diese (glaube ich) auch mit auf die Postscript-Reise. (Ich wüsste allerdings nicht, wo man dieses ein oder ausschaltet, wie damals in OS9-Zeiten). Wie dem auch sei - kennt jemand dieses Problem und kann mir helfen?

Übrigens - beim Distiller unter OSX hatten wir dieses Problem auch mal, haben aber durch Angeben eines separaten Schriften-Ordners im Distiller das Problem lösen können.

Wir haben jetzt unter der Windows-Maschine auch eine Helvetica installiert; diese taucht unter EtherShare-Admin in der Fontliste des Druckers auch auf - scheint aber nicht die "Richtige" zu sein.

Macht mir bitte ein Weihnachtsgeschenk und helft mir :-) Danke

Hallo Olaf

Zitat

Übrigens - beim Distiller unter OSX hatten wir dieses Problem auch mal, haben aber durch Angeben eines separaten Schriften-Ordners im Distiller das Problem lösen können.

Das ist die Lösung. Wir haben fast die selbe Lösung am laufen mit dem Unterschied dass der Distiller bei uns unter Unix läuft. Ich musste mit dem Schalter "-f" den Pfad zum Fontsorder angeben in der ich die Helvetica kopiert habe. Schau mal in der Doku nach wie das unter Win funktioniert.

Gruss Jürg

Hallo Jürg...

vielen Dank für deine schnelle Reaktion.
Aber - tut mir leid - ich wüsste nicht, wo man in Helios einen Schalter "-f" setzen kann, der den Fontordner definiert.
Ich kann leider unter Windows die entsprechende Helvetica nicht "installieren", da es sich um eine Mac-Helvetica handelt. (Alle anderen Fonts, die ich unter Windows installiert habe, tauchen auch in der Fontliste des Druckers unter Helios auf.)

Und unter Helios zusätzliche Fonts angeben, funktioniert zwar generell - aber nicht mit der System-Helvetica (von der ich glaube, dass es die "richtige" ist. Helios sagt bei dem Versuch sie unter EtherShare-Admin in die Fontliste mit aufzunehmen: Ist keine Postscript-Schrift).

Please help ---- thanx

Guten Tag

Sie benötigen die PFM und PFB Dateien der Helvetica. Diese sind im Distiller in die Schriftenordner aufzunehmen. Danach die Batch Datei zum Übernehmen der Distillersettings ausführen. Danach eventuell den Dienst stoppen und wieder starten.

Wie ist Ihre eMail adresse?

Meinen Sie den Schriftenordner sozusagen unter Helios EtherShare-Admin?

Meine E-Mail-Adresse: olaf.giesxxx@filestxxx.xxx

Vielen Dank im voraus - Olaf Giesick

Hallo

Nein, der Schriftenordner muss im Distiller am PC zugewiesen werden. Damit der PDF-Handshake Dienst diese geänderte Distillerkonfiguration mitbekommt, muss man die Batchdatei ausführen. Im Ethershare Admin ist es nicht notwendig Schriften zu laden.

Nach dem Hinzufügen der Schriften (stellen Sie in diesem Fall sicher, dass nur der Acrobat Resource Fonts und der neue Schriftenordner zugewiesen sind) erzeugen Sie für den Drucker im Helios Admin eine neue Schriftenliste.

Das wars

Muss die Schriften erst suchen - Sie hören von mir

Hallo Peter,

ist es denn nicht eigentlich gängige Praxis, anstelle von Workarounds zu versuchen, das Problem an sich zu lösen? Und "das Problem" stellt sich mir etwas globaler dar:

Es geht darum, die Kombination aus Anwendungsprogramm und Druckertreiber auf den Arbeitsplätzen dazu zu nötigen, sämtliche dort lokal im Dokument vorhandenen Schriften in den entstehenden PostScript-Stream einzubetten und damit einen Rückgriff auf

* Schriften im Helios' Fontserver
* Schriften im Ausgabegerät (sei es Distiller oder druckerresidente Fonts)

effektiv zu verhindern. Solange das einzige Differenzierungskriterium bei der Schriftsubstitution im PostScript-Bereich der reine Schriftenname ist, kann ich mir irgendwie keinen anderen Weg vorstellen, im Sinne der Produktionssicherheit vorzugehen.

Siehst Du das anders?

Gruss,

Thomas

Hallo,

Zitat

> Leider schreibt der Server keine PDFs von Quark und Freehand-Dateien, weil
> im Drucker-Log unter EtherShare-Admin angezeigt wird, das die Helvetica fehlt.

Meines Erachtens gehören hier anstelle von Workarounds (und nicht mehr ist die Schriftsubstitution im Server/Distiller/Drucker, wenn man denn nicht auch gewährleisten kann, immer mit exakt identischen Schriften zu hantieren) Lösungen her.

Und die wäre: Die Anwendung zwingen, sämtliche im Dokument vorhandenen Schriften gleich von vorneherein einzubetten.

Wie das geht? Je nach Anwendung verschieden. In InDesign sollte das Anklicken von "PPD-Schriftarten herunterladen" genügen.

Generell sollte die Verwendung findende PPD um sämtliche Schriftinformationen erleichtert werden, um in Situationen, wo der Druckertreiber oder die Anwendung eine Entscheidung über lokales Einbetten von Schriftresourcen nur anhand dieser Informationen trifft, eindeutig zugunsten lokaler Einbettung entschieden wird.

Unter MacOS 9 und bei Verwendung von AppleTalk oder Helios TCL/SLP war die Welt noch schön einfach: Hier reichte es, auf dem Server die Schriftenliste des Spoolers zu entleeren, um Dank bidirektionaler Kommunikation in der Kette Anwendungsprogramm <--> LaserWriter Treiber <--> Helios-Spooler für eine lokale Einbettung von Schriften in den PostScript-Ausgabestream zu sorgen.

Das stellt sich leider mit dem an der Stelle deutlich ineffizienteren Spoolsystem unter MacOS X nicht mehr so simpel dar. Hier hängt es dann meist von der lokal zugewiesenen PPD und Anwendungs-spezifischen Einstellungen im Druckdialog ab, ob Schriften lokal eingebettet werden oder darauf vertraut wird, daß diese "später" im Workflow noch von der ein oder anderen Instanz (Helios' Fontserver oder Distiller und seine Fontordner) bereitgestellt werden können.

Damit mich niemand falsch versteht: Wenn man wirklich sicherstellen kann, auf den Client-Arbeitsplätzen immer und ausschließlich die Schriften zu verwenden, die auch auf dem Server bzw. Ausgabegerät geladen sind, dann kann man zur Reduktion von Netzwerk-Traffic ruhig damit arbeiten, daß keine lokale Einbettung von Schriften schon am Arbeitsplatz geschieht. Aber wer kann das schon? Wo es doch alleine zig offizielle Varianten der Helvetica seitens Adobe in den letzten zwei Dekaden gegeben hat?

Gruss,

Thomas

Hallo Thomas

Es geht im Grunde nur darum, dem Distiller die per Definition Base 14 Schriften zu hinterlegen. Es gibt Programme die auf Basis der Helvetica Berechnungen durchführen, obwohl die Schrift gar nicht im Dokument vorhanden ist. Diese Programme Arbeiten auf dem Hintergrund, dass jeder PostScript Rip diese Schriften im Speicher hat (wie es ja sonst bei allen anderen RIP, auch wenn diese nicht von Adobe sind, der Fall ist.

Früher dachte ich auch so wie du, aber mittlerweile kam ich der Überzeugung, dass es von Adobe ein Fehler ist dem Distiller (einem Adobe PS-Interpreter) diese Base 14 Schriften zu hinterlegen. Darum ist das kein Workaround, sondern ein Fix.

Im Falle jeder anderen Schrift teile ich Deine Meinung. Verwendete Schriften müssen mitgeschickt werden.

Hallo Peter,
vielen Dank für die Idee - wenn Sie die entsprechenden Fonts noch bei sich finden würden, wäre ich sehr dankbar - hört sich sehr gut an, die Vorgehensweise.

Ich gebe allerdings auch Herrn Kaiser Recht, der die "direkte" Lösung - und nicht den Workaround - präferieren würde.
Damit habe ich mich natürlich zu Beginn meiner Problemlösung beschäftigt, bin aber, was die beiden Anwendungsprogramme Quark und Freehand angeht, gescheitert.
Ich weiß weder, warum Quark und Freehand für die korrekte Postscript-Ausgabe jedesmal die Helvetica benötigen, noch, an welcher Stelle im Drucken-Workflow unter OSX die Schrifteneinbettung erzwungen werden kann. (In der Acrobat-PPD definitiv nicht.)

Ich habe parallel zu diesem Forumsbeitrag mal mit einem Bekannten telefoniert, der mir den Tipp gegeben hat, die Helvetica.dfont-Datei aus dem System zu deaktivieren. (OSX 10.4 - Tiger)

Und siehe da - es funzt ...

Nur leider verstehe ich die Lösung nicht:
Ist die Helvetica im System installiert, wird der entsprechende Verweis in die Postscript-Datei von Quark geschrieben - und ist die Helvetica im System NICHT installiert, wird der entsprechende Verweis von Quark auch nicht in die PS-Datei geschrieben ...

HÄÄÄ???

Kommt noch der letzte Punkt hinzu: Laut David Uhlhorns "Fonthandling Mac OS X Tiger" (www.werkflow.ch) wird die Helvetica.dfont von Apples "Mail, Safari, Adressbuch" benötigt, so dass ich sie auf Grund dessen nur ungern im System deaktiviere ...

Nichts genaues weiß man nicht - vielen Dank für eure Mühe

Kleiner Nachtrag:

Die Bemerkung, dass es jetzt funktioniert, nachdem ich die Helvetica.dfont deaktiviert habe - darf ich so nicht stehen lassen. Es wird nachwievor eine Fehlermeldung in EtherShare-Admin ausgewiesen - es wird aber wenigstens ein PDF erzeugt.
Vorher: Fehlermeldung und KEIN PDF ...

Ein weiterer Nachtrag und ein Dankeschön an Peter Kleinheider - den Fontordner wie beschrieben am Distiller einrichten und schon funktioniert's auch mit Quark ...

Danke und schöne Weihnachtstage aus Hamburg

Hallo Olaf,

ich muß Peter recht geben in Bezug auf die Base14-Fonts, auch wenn ich nach wie vor ein Problem darin sehe, falls im lokalen Dokument eine solche Schrift Verwendung findet, nicht mitgeschickt wird und dann durch eine falsche Version substituiert wird (ein Kunde konnte deshalb mal einen kompletten Geschäftsbericht aufgrund fehlendem Euro-Zeichen einstampfen lassen. War aber eh unter typografischen Gesichtspunkten betrachtet das Beste ;-)

Dann zum Thema PPDs in MacOS X. Wichtig ist, daß man bei Veränderungen die richtige erwischt. Und die liegt -- wenn man darauf verzichtet, eine modifizierte zuzuweisen -- unterhalb /etc/cups/ppd/ und ist so benannt wie der interne Spoolername auf dem Mac. Der folgende häßliche Bandwurm kann -- so er in einer Zeile in Terminal.app am Stück eingegeben wird -- je PPD bzw. lokal angelegtem Drucker die in der PPD aufgeführten Schriften ausgeben:

    

Code

for file in /etc/cups/ppd/*.ppd ; do basename "$file" .ppd ; cupstestppd -vv "$file" | grep " = Font " | sort | awk -F"Font" '{print $2}' | cut -d: -f1 | tr " " "\t" ; done 

Bei aktuellen Distiller-PPDs ist da eh außer 4 Courier-Schnitten und Symbol nichts mehr zu finden.

Abschließend zum Thema Schriften in MacOS X:

     http://www.linotype.com/fontexplorerX
     http://docs.info.apple.com/...le.html?artnum=25486
     http://www.pdflib.com/de/produkte/mehr/bibel/
     http://homepage.mac.com/mdouma46/fontfinagler/
     http://homepage.mac.com/...a46/dfont/dfont.html

Und bzgl. Debugging ist es ratsam, auf dem Helios-Server eine "In Datei Drucken"-Queue einzurichten, der exakt diesselbe PPD zugewiesen wird, wie die Produktions-Queue, um die es geht. Diese "In Datei Drucken"-Queue am Besten nicht als PS-fähig deklarieren, dann aber trotzdem am Client wenn nötig die selbe PPD zuweisen (und dann von Hand bzw. mit einem passenden Texteditor -- bspw. TextWrangler -- die PPDs beider Queues auf dem Client in /etc/cups/ppd/ vergleichen)

Wenn man dann in die Print-to-Disk-Queue hineindruckt, legt Helios exakt den PostScript-Stream, der vom Client abgeschickt wird, ohne Modifikationen in einem PS-File ab. Das kann man dann passend analysieren. Spannend sind hier die DSC-Kommentare, die sich um Resourcen drehen, also:

%%DocumentNeededResources:
%%DocumentSuppliedResources:

Man kann sich relativ simpel alle DSC-relevanten Informationen innerhalb einer PS-Datei unter Unix (also auch MacOS X) mit folgendem Kommando ausgeben lassen:

    

Code

tr "\015" "\012" < foo.ps | grep "^%%" 

(foo.ps natürlich durch den Namen der PS-Datei ersetzen).

Gruss,

Thomas

Halo Thomas,

> ich muß Peter recht geben in Bezug auf die Base14-Fonts,
> auch wenn ich nach wie vor ein Problem darin sehe, falls
> im lokalen Dokument eine solche Schrift Verwendung findet,
> nicht mitgeschickt wird und dann durch eine falsche Version
> substituiert wird (ein Kunde konnte deshalb mal einen
> kompletten Geschäftsbericht aufgrund fehlendem Euro-Zeichen
> einstampfen lassen. War aber eh unter typografischen
> Gesichtspunkten betrachtet das Beste ;-)

Da muss ich jetzt aber mal nachfragen. Nach meiner Erfahrung hat eine per Druckjob mitgelieferte Schrift Priorität vor PPD oder Drucker Fonts. Ansonsten wäre die ganze Mitschickerei von Base13 Fonts auf ältere RIPS ja völlig für die Füsse.

MfG

Thomas

Hallo Thomas

Das ist korrekt.

Thomas Kaiser hat nur den Fall angesprochen, dass z.B. eine Hlevetica verwendet wurde, diese, aus welchem Grund auch immer, nicht mitgeschickt wurde und dadurch die im Rip befindliche verwendet wird.