Hallo,

ich habe im Netzwerk immer noch eine DC12 als Netzwerkdrucker stehen, die von einem Splash-G620-RIP angesteuert wird. Obwohl die Kombi sicherlich in die Jahre gekommen ist bin ich von der Halbton-ähnlichen Druckqualität immer noch angetan und möchte das Gerät gerne noch weiter nutzen. Aber ich sehe da einige Probleme auf mich zukommen, da das Gerät nur per Apple-Talk angesprochen werden kann. Der letzte Treiber für das Splash-RIP ist von 2001. Im Internet ist auch eine Version von 2004 gelistet, die aber identisch zur 2001 ist.

Bisher hatte ich keine Probleme, das Gerät anzusteuern. OS-X 10.5 kommt mit dem Uralt-Treiber problemlos zurecht und unter Win-XP konnte ich mit dem nachgerüsteten Apple-Talk aus Windows-2000 ebenfalls mit dem Original-Treiber arbeiten. Windows-7 unterstützt aber nun definitiv kein Apple-Talk mehr und der Nachrüst-Trick funzt leider nicht. Ein Windows-7-Treiber - geschweige denn in 64bit - ist ebenfalls nicht verfügbar.

Jetzt die Helios-Noob-Frage:
Helios kann doch Apple-Talk. Und einen Spooler für die DC12 habe ich auch eingerichtet, der von 10.4/10.5/XP verwendet werden kann. Was liegt also näher, als über Helios auf die DC12 zu drucken? Bekomme ich aber nicht hin. Eben, weil ich keinen Treiber auf der Windows-Maschine habe. Wie macht man das? Gebe gerne zu, dass ich da mit Helios nicht wirklich viel Erfahrung habe als Mausschubser, aber eigentlich dachte ich, dass das die ureigenste Aufgabe von Helios als Printserver ist.

Das gleiche Problem wird auf mich zukommen, wenn ich den Prinergy-Server von Win-2003-Server auf Win-2008-Server update, da der ja ebenfalls kein Apple-Talk mehr kann. Bisher dachte ich da ebenfalls, einfach über Helios drucken zu können. Aber das wird mich wohl vor ähnliche Probleme stellen.

Und 10.6 wird dann doch auch rumzicken mangels Apple-Talk, oder? Wollte mit Erscheinen der CS5 eigentlich neue Mac-Pros kaufen, die dann natürlich 10.6 haben. Kann ich dann auch nicht mehr drucken oder wie muß ich mir das dann vorstellen?

Wäre über jeden erhellenden Tip dankbar. Habe natürlich einen aktuellen Farbdrucker im Netz, der keine Probleme macht, aber hier geht es speziell um die DC12, die ich gerne noch weiter nutzen möchte - möglichst ohne in ein anderes RIP zu investieren.

Gruß

Hallo,

Antwort auf [ rohrfrei ]

Helios kann doch Apple-Talk. Und einen Spooler für die DC12 habe ich auch eingerichtet, der von 10.4/10.5/XP verwendet werden kann. Was liegt also näher, als über Helios auf die DC12 zu drucken? Bekomme ich aber nicht hin.

Also wenn ich's recht verstehe, willst Du von Windows aus auf Helios drucken und glaubst, Dir fehlt ein "Treiber"? Da die DC12 PostScript kann, brauchst Du keinen Treiber sondern kannst den eingebauten PostScript-Treiber von Windows nutzen.

Es braucht nur 'ne PPD und eine ".inf"-Datei (zumindest bis einschließlich Windows XP -- was Höheres hab ich zum Glück noch bei keinem Kunden gesehen und demzufolge auch null Ahnung, wie das da bzgl. Drucken geht).

Diese .inf-Datei legt man neben die PPD, paßt den Inhalt entsprechend an (der Name der PPD-Datei muß korrekt referenziert werden) und basta. Und natürlich auf die Zeilenenden der PPD und dieser .inf-Datei achten. Die sollten passend für Windows ausfallen.

So 'ne .inf-Datei für eine PPD mit dem Namen "ADPDF.PPD" sieht bspw. so aus:

Code

[Version] 
Signature="$Windows NT$" 
Provider=%MS% 
ClassGUID={4D36E979-E325-11CE-BFC1-08002BE10318} 
Class=Printer 
LayoutFile=layout.inf 
DriverVer=03/25/2002 
 
[Manufacturer] 
"Kaiser" 
 
[Kaiser] 
"Adobe Distiller" = ADPDF.PPD,Distiller 
 
[ADPDF.PPD] 
CopyFiles=@ADPDF.PPD 
DataSection=PSCRIPT_DATA 
DataFile=ADPDF.PPD 
Include=NTPRINT.INF 
Needs=PSCRIPT.OEM 
 
[DestinationDirs] 
DefaultDestDir=66000 
 
[Strings] 
MS="Microsoft" 

Beispielmaterial (PPD und .inf) hier:

http://kaiser-edv.de/downloads/ADPDF.zip

Antwort auf:

Und 10.6 wird dann doch auch rumzicken mangels Apple-Talk, oder? Wollte mit Erscheinen der CS5 eigentlich neue Mac-Pros kaufen, die dann natürlich 10.6 haben. Kann ich dann auch nicht mehr drucken oder wie muß ich mir das dann vorstellen?

10.6 hat kein AppleTalk mehr. Solange Du Helios auf einem Server laufen hast, der noch mit AppleTalk-Support daherkommt (und solange Helios noch AppleTalk unterstützt -- auf manchen Plattformen machen sie das jetzt ja schon nicht mehr) kann der dann das Bindeglied zu Ausgabegeräten spielen, die auf AppleTalk setzen. Zwischen dem Mac und dem Helios-Server mußt Du dann eben ein anderes Protokoll nutzen (remote LPR, TCP/IP Streams, IPP oder SMB)

Gruss,

Thomas

Hallo,

also der "Treiber" besteht bei mir aus einer Sammlung von verschiedenen Dateien. Unter anderem auch einer korrekten .inf und einer .ppd - siehe screenshot.

Bei der Installation dessen kommt aber eine Fehlermeldung wie im anderen screenshot dargestellt. Das passiert sowohl mit meinem Splash-Treiber als auch mit den Kaiser-Beispieldaten.

Er scheint sich da über irgendwas zu beschweren hinsichtlich x64. Oder ist es so etwas ähnliches wie beim Kernel-Treiber-Problem unter Win2003-Server? Das muss man da ja auch erst künstlich frei schalten in den Gruppenrichtlinien. Ist es denkbar, dass es so etwas auch in Windows-7 gibt?

Zitat

Zwischen dem Mac und dem Helios-Server mußt Du dann eben ein anderes Protokoll nutzen (remote LPR, TCP/IP Streams, IPP oder SMB)

Katsching! Alles klar, habe verstanden, danke.

Gruß

Hallo,

Antwort auf [ rohrfrei ]

Bei der Installation dessen kommt aber eine Fehlermeldung wie im anderen screenshot dargestellt. Das passiert sowohl mit meinem Splash-Treiber als auch mit den Kaiser-Beispieldaten.

Er scheint sich da über irgendwas zu beschweren hinsichtlich x64.

Wie schon geschrieben: Ich hab keinerlei Ahnung bzgl. des Druckkrams ab Vista. Grad mal Google mit »x64 driver inf ppd« beworfen, führt zu einigen Tipps (das Problem an sich hat ja überhaupt nichts mit Helios zu tun sondern ist ein Windows-generisches)

Gruss,

Thomas

Hallo,

ist schon richtig. Die DLLs sind nicht für 64bit geeignet. Das scheint das Problem zu sein. Habe jetzt einen Windows-default-Drucker aus der Liste genommen. Das ist ein Xerox Phaser 6180 DN PS. Mit dem kann ich zumindest in Farbe drucken. Leider nur DIN A4. Sämtliche Druckeroptionen des Splashs bleiben mir so verborgen, aber für e-mails wird es reichen. Wenn ich echte Dokumente drucken muß, dann gehe ich über den Mac. Ist übrigens komisch, dass ich mit keinem der Windows-eigenen Drucker von Xerox in A3 drucken kann. Selbst mit dem Treiber der iGen nicht. Aber die neuen Xerox-Treiber sind nett anzuschauen...

Dann habe ich heute mal versucht, einfach die bereits installierten DLLs und andere Dateien aus dem x64-Ordner von Windows mit meiner .inf zu vermischen. Aber das scheitert dann an den Driver- und Config-DLLs, die ich natürlich nicht neu programmieren kann in 64bit.

Zitat

Ich hab keinerlei Ahnung bzgl. des Druckkrams ab Vista.

Schade. Dann kennst du auch keine Möglichkeit einen 32bit-Treiber - natürlich auch noch unzertifiziert - auf einem 64bit-System zu installieren?

Gruß

Hi,

Antwort auf [ rohrfrei ]

Dann kennst du auch keine Möglichkeit einen 32bit-Treiber - natürlich auch noch unzertifiziert - auf einem 64bit-System zu installieren?

Nein, interessiert mich auch nicht sonderlich, weil es keine Treiber braucht -- Windows hat doch seit mindestens 10 Jahren leidlich korrekt arbeitende PostScript-Treiber an Bord? Die man durch Auswählen der richtigen PPD auch korrekt parametrisieren kann?

Ich bleib dabei: Der .inf-Weg muß reichen. Die 64-Bit-Varianten wollen halt die .inf-Datei bisserl anders frisiert haben. Ich hab ja vorhin schon die Google-Suchbegriffe gepostet. Auf der ersten Ergebnisseite bzw. unter den ersten 10 Treffern findet sich:

     http://www.rumborak.de/forum/viewtopic.php?TopicID=1271

Gruss,

Thomas

das ja ne tolle Seite ;-)

Kann ja sein, dass die das damit hinbekommen haben, aber die verweisen ja auch in der inf-Datei auf keine DLLs. Bei mir sieht das aber so aus:

Code

; SPG630.INF 
; 
; Splash G630-DocuColor 12, .inf 
; 
 
[Version] 
Signature="$CHICAGO$" 
Provider=%EFI% 
ClassGUID={4D36E979-E325-11CE-BFC1-08002BE10318} 
Class=Printer 
;CatalogFile=g630_ntx86.cat 
;DriverVer=11/07/2000, 3.0.0.0 
 
 
[Manufacturer] 
"EFI" 
 
 
[EFI] 
"Splash G630-DocuColor 12"                    = SPG630.PPD 
 
 
[SPG630.PPD] 
CopyFiles=@SPG630.PPD,@SPG630UI.DLL,@SPG630.INI,@SPG630KM.DLL,PSCRIPT 
DataSection=PSCRIPT_DATA 
 
 
[SourceDisksNames] 
1="G630 INF",,,"." 
 
 
[SourceDisksFiles] 
SPG630.PPD=1 
SPG630UI.DLL=1 
SPG630.INI=1 
SPG630KM.DLL=1 
ADOBEPS5.DLL=1 
ADOBEPSU.DLL=1 
ADOBEPSU.HLP=1 
ADOBEPS5.NTF=1 
 
 
[PSCRIPT] 
ADOBEPS5.DLL 
ADOBEPSU.DLL 
ADOBEPSU.HLP 
ADOBEPS5.NTF 
 
 
[PSCRIPT_DATA] 
DriverFile=ADOBEPS5.DLL 
ConfigFile=ADOBEPSU.DLL 
HelpFile=ADOBEPSU.HLP 
 
 
[DestinationDirs] 
HelpFiles=10 
DefaultDestDir=66000 
 
 
[ControlFlags] 
ExcludeFromSelect = 2369 
 
[Strings] 
EFI="Electronics For Imaging, Inc." 

Was soll ich da jetzt wie ersetzen, um das 64bittig zu machen?

Gruß

Hi,

Antwort auf [ rohrfrei ]

das ja ne tolle Seite ;-)

Diese Seite von Wolfgang Reszel (hier auf HDS nebenan übrigens auch mal Moderator gewesen) mag bisserl altbacken ausschauen, dürfte aber die Adresse sein, wenn es um PostScript- und PDF-Erstellung mit Windows-Bordmitteln geht. Und das locker seit 10 Jahren. So viel schon mal vorausschickend. Das Beispielmaterial, das ich hier gepostet habe, entstand auch durch Adaption von Wolfgangs Vorarbeiten.

Antwort auf:

Kann ja sein, dass die das damit hinbekommen haben, aber die verweisen ja auch in der inf-Datei auf keine DLLs.

Ja, mei, weil's das nicht braucht? Mag ja sein, daß Xerox/EFI es für eine tolle Idee hält, den AdobePS zu bundlen (anstatt den Windows-eigenen PS-Treiber zu nehmen, der seit 10-15 Jahren auch nix weiter als ein von Adobe lizensierter AdobePS ist, wenn mich meine Erinnerung nicht täuscht). Und mag ja sein, daß Du Dich weiterhin fragst, wie Du einen 32-Bit-Treiber unter einem 64-Bit-Windows zum Laufen bekommen kannst.

Mein Ansatz ist nach wie vor ein anderer: Auf PSCRIPT.OEM anstelle Adobes Kram setzen und gut ist. D.h. die .inf-Datei passend modifizieren.

Antwort auf:

Was soll ich da jetzt wie ersetzen, um das 64bittig zu machen?

Weder Ahnung, noch Zeit/Lust, dieser Windows-Frage nachzugehen. Wenn ich's müsste, d.h. per Gewaltandrohung oder pekuniären Verlockungen gefügig gemacht werden würde, würde ich wahrscheinlich nach »".inf" NTamd64« oder sowas googlen und dann die Änderungen an der .inf-Datei machen.

Und nochmal der Hinweis: Das ist alles nix Helios-Spezifisches, d.h. die Chancen, ausgerechnet hier zielführende Antworten zu bekommen, etvt. nicht allzu groß (was nicht automatisch heißen soll, daß im Windows-Forum nebenan mehr Hilfe zu erwarten ist)

Gruss,

Thomas

Hallo,

ich wollte da keinem zu nahe treten. Aber die Seite kannte ich noch nicht. Der Name und die Sonderzeichen in den Beiträgen sehen aber schon komisch aus. War Rumborak nicht der mit dem Zauberring?

Egal, habe es jetzt hinbekommen. Funktioniert grundsätzlich. Aber die beiden EFI-spezifisichen DLLs erzeugten Fehler, so dass ich sie entfernen musste. Und gerade die sind wohl für die Druckerspezifischen Einstellungen wie Wendung, Heftung etc. verantwortlich. Ergo, ohne die DLLs keine individuellen Einstellungen. Aber immerhin funktioniert es jetzt grundsätzlich und ich kann schon mal A4 und A3 drucken.

Danke, du hast mir sehr geholfen.

Gruß

Hi,

Antwort auf [ rohrfrei ]

ich wollte da keinem zu nahe treten.

Und ich hoffe, Du hast meinen "Tonfall" nicht in den falschen Hals bekommen. Wollte eben nur wiederholt andeuten, daß das Problem an 'ner anderen Stelle zu suchen bzw. lösen ist.

Antwort auf:

Egal, habe es jetzt hinbekommen. Funktioniert grundsätzlich. Aber die beiden EFI-spezifisichen DLLs erzeugten Fehler, so dass ich sie entfernen musste. Und gerade die sind wohl für die Druckerspezifischen Einstellungen wie Wendung, Heftung etc. verantwortlich.

Saublöd, aber da scheinen die irgendwie drauf zu stehen, Funktionalität, die man ggf. auch direkt via PPD/drucker-intern abbilden könnte, in client-seitige Software zu gießen. Unter MacOS X wird ja auch jede Fiery-PPD immer mit einem Verweis auf den fierycupsfilter "verseucht", der dann letztlich aber gar nicht so viel macht.

Ich hab zum Glück zu wenig mit Fiery-RIPs zu tun (regelmäßig nicht "mein Tisch" in Kundeninstallationen). Aber wäre da mehr, würde ich mir das mal en Detail anschauen, ob man nicht auf die DLLs verzichten kann und trotzdem zum Ziel kommt.

Erster Test wäre, eine Macintosh-PPD von den Zeilenenden her auf Windows zu frisieren und dann via des .inf-Mechanismus an Windows zu verfüttern und dann zu gucken, was geht.

Ist hier zwar alles eher off-topic, würde mich (und einige stille Mitleser sicherlich auch) aber interessieren, falls Du hier weiterforschen solltest.

Gruss,

Thomas

Zitat

Erster Test wäre, eine Macintosh-PPD von den Zeilenenden her auf Windows zu frisieren und dann via des .inf-Mechanismus an Windows zu verfüttern und dann zu gucken, was geht.

coole Idee. Habe mir die Win- und die Mac-PPD angesehen. Die sind absolut identisch bis auf die Tatsache, dass in der Mac-PPD zusätzlich noch die Gerätetypischen Eigenschaften aufgeführt sind. Das kann man mehr oder weniger in Klartext lesen. Und das sind genau die Reiter im Druckertreiber die das Gerät individuell ansteuern.

Daraufhin habe ich diese Mac-PPD dem Windows-Treiber eingeimpft. Leider ohne Erfolg. Aber nur im ersten Schuß. Habe aus Bequemlichkeit lediglich die Dateien ersetzt und nicht die Namen geändert. Daraufhin änderte sich rein gar nix. Also nochmal rangesetzt und komplett alles umgeschrieben und neu getestet. Und siehe da, es funktioniert. Zwar nicht so schön wie vorher in den Reitern, aber egal, Hauptsache die Funktionen sind da. Und das sind sie. Schön untereinander unter Merkmale einer nach dem anderen. Wenn man mit dem Treiber seit fast 10 Jahren gearbeitet hat, ist es kein Problem, dann findet man sich schnell zurecht.

Vielen Dank.

Gruß

Hi,

Antwort auf [ rohrfrei ]

Daraufhin habe ich diese Mac-PPD dem Windows-Treiber eingeimpft. Leider ohne Erfolg. Aber nur im ersten Schuß. Habe aus Bequemlichkeit lediglich die Dateien ersetzt und nicht die Namen geändert. Daraufhin änderte sich rein gar nix. Also nochmal rangesetzt und komplett alles umgeschrieben und neu getestet. Und siehe da, es funktioniert.

Fein bzw. "war zu erwarten" . Nee, im Ernst: Das muß ja schlichtweg auch so gehen, denn wenn das über generische PPD-Features parametrisierbar ist, dann hat das auch unter Windows abseits irgendwelcher DLLs, die das evtl. hübscher präsentieren, zu funktionieren.

Ist übrigens am Mac nicht anders. Da gibt es auch einige Lösungen, die auf sog. PDE (Printer Dialog Extensions, also native MacOS X Programme, die quasi als Plug-Ins für den Druck-Dialog agieren -- und so manches mal rumzicken bspw. wenn nicht Intel-nativ sondern nur als PPC-Version verfügbar, etc.) setzen, mit denen dann dies und das parametrisiert wird. Letzten Endes kann man all das aber auch bekommen, indem man eine generische PPD nimmt, in der dann die Parameter als PPD-Features verpackt ins Drucksystem geschleust werden.

Egal.

Drei Sachen noch:

1) Ein kleiner Schönheitsfehler sind die defekten Umlaute in Deinem Druckdialog bzw. Screenshot. Sollte vermutlich reichen, die PPD-Datei, die UTF-8 kodiert vorliegen dürfte, in einem Texteditor nach "ISO 8859-1" oder dieses komische Windows-1251 (oder so) Encoding umzuwandeln und erneut zu importieren.

2) es wäre schick, wenn Du PPD und .inf-Datei(en) irgendwo online stellen oder an Dein nächstes Posting tackern könntest. Fein wäre sowohl die 64-Bit-.inf Datei als auch das unmodifizierte Original ins Paket zu packen, damit andere evtl. schneller diese Ummodelei für andere PPDs adaptieren können.

3) Und dann bitte nicht vergessen, auf dieses Posting im Windows- und den passenden Prepress-Foren zu verlinken. Ich denke für solche Lösungen abseits "herstellereigenen" (auf die man ja gerne mal Monate bis Jahre warten darf) gibt es durchaus Bedarf in der Community.

Gruss,

Tgomas

Hallo,

hm, wäre das überhaupt legal? Eine nicht autorisierte Veränderung? Und dann auch noch öffentlich stellen? Die Rechte hat ja eigentlich immer noch EFI. Davon würde ich jetzt erstmal Abstand nehmen wollen. Ich habe aber die Überschrift verändert, dass man zumindest per Google hierhin kommt. Mit den o.g. Beiträgen sollte man das dann nachvollziehen können. Habe ich ja immerhin auch geschafft und ich habe noch nicht einmal in meinem Leben ein Terminal oder eine Konsole freiwillig aufgemacht.

Gruß