Der Umstieg naht ...
Achim Denzl
langsam ist es soweit, und unser erster Satz-Arbeitsplatz wird in den
nächsten Wochen auf OS X umgestellt ;-/
Leider gibt's immer noch ein paar ungelöste Probleme, die einem
professionellen Arbeiten im DTP-Bereich im Wege stehen. Und bevor ich
mich in Google stürze, frage ich erst mal hier nach, ob schon jemand ein
paar Lösungen parat hat.
1. Zeichensätze
Suitcase läuft ganz ordentlich unter OS X, was allerdings fehlt ist
TypeReunion, also ein Utility, das im Zeichensatzmenü die Fonts nach
entsprechenden Gruppen gliedert. MenuFonts läuft IIRC auch nicht unter
OS X. Gibt's da zwischenzeitlich was?
2. Tastaturkürzel
Viele Tastaturkürzel, die eigentlich für Funktionen im
Anwendungsprogramm vorgesehen sind, werden unter OS X rigoros vom System
bzw. Dock.app abgefangen (Apfel-Tab, Apfel-Alt-D, Apfel-<, Apfel->, ...)
Wenn ich das Dock komplett deaktiviere, wird der login-Prozess nicht
sauber abgeschlossen, also auch keine Lösung. Könnte es eventuell mit
QuickKeys funktionieren? Oder gibt's irgendeine andere Lösung?
3. Native OS X Applications
Es fehlen leider immer noch einige Key-Applikationen. Vielleicht weiß ja
jemand (ohne erst Google zu bemühen ;-), ob und wann Portierungen
geplant sind: Adobe Distiller, Tailor, FontIncluder ...
4. PrintCenter
Fast alle unsere Drucker/Belichter/Spooler werden mit PAP angesprochen.
Soweit alles OK. Allerdings macht sich bei knapp zwei Dutzend Queues das
Fehlen der Schreibtischdrucker-Symbole schon deutlich negativ bemerkbar;
das PrintCenter ist IMHO kein brauchbarer Ersatz, um schnell zwischen
Druckern umzuschalten und um alle Drucker gleichzeitig im Blick zu
haben. Auch das Argument, dass man ja jetzt alle Drucker im
Drucken-Dialog der Applikation auswählen könne, ist keine wirkliche
Hilfe. Außerdem kann ich IIRC im PrintCenter keinen verbindungslosen
Drucker zum Sichern einer Postscript-Datei anlegen, was die
Zusammenarbeit mit Distiller-Hotfoldern ebenfalls erschwert.
Irgendwelche Ideen?
5. Server
Wir haben ein paar Server mit relativ vielen ServerVolumes. Die
Anbindung mittels afp (tcp) klappt gut, nur das Automount über die
Startobjekte gefällt mir nicht, da beim login dann immer auch gleich die
Fenster geöffnet werden anstatt nur die Symbole auf dem Desktop
anzuzeigen. Lösung über AppleScript wäre wohl möglich, aber vielleicht
gibt's was Eleganteres?
to be continued ...
... falls mir noch was einfällt ;-)
Ciao
Achim,
sich schon riesig darauf freuend, dann endlich auch Safari im Büro
einsetzen zu können ;-)
--
Heute mal mit MacSoup unter OS X ;-)
Christian Schmitz
> Hallo NG,
>
> 1. Zeichensätze
> Suitcase läuft ganz ordentlich unter OS X, was allerdings fehlt ist
> TypeReunion, also ein Utility, das im Zeichensatzmenü die Fonts nach
> entsprechenden Gruppen gliedert. MenuFonts läuft IIRC auch nicht unter
> OS X. Gibt's da zwischenzeitlich was?
Ich glaube nicht, daß irgendwer meine Programme hackt und mir das Menü
umbaut, wo's doch Speicherschutz geben soll..
> 5. Server
> Wir haben ein paar Server mit relativ vielen ServerVolumes. Die Anbindung
> mittels afp (tcp) klappt gut, nur das Automount über die Startobjekte
> gefällt mir nicht, da beim login dann immer auch gleich die Fenster
> geöffnet werden anstatt nur die Symbole auf dem Desktop anzuzeigen. Lösung
> über AppleScript wäre wohl möglich, aber vielleicht gibt's was
> Eleganteres?
Mit Realbasic könnte ich dir sicher schnell was schreiben, was beim
Starten in einer Textdatei server, name und passwort ausliesst und die
Server mountet...
(AFP Klassen im MBS Plugin)
Mfg
Christian
--
Three thousand functions in one REALbasic plug-in. The MBS Plugin.
Matthias Tillmans
> Vielleicht weiß ja jemand (ohne erst Google zu bemühen ;-), ob und wann
> Portierungen geplant sind: Adobe Distiller, Tailor, FontIncluder ...
Zu Enfocus Tailor: Die Entwicklung ist mit der Version 2.0.8 zugunsten
der PDF-Produkte (Pitstop usw.) eingestellt worden. Eine OS X-Version
wird es nicht geben. Schade, vor allem weil Tailor ja von der
NEXT-Plattform kam, allerdings dort die Display PS-Engine nutzen konnte.
--
Matthias Tillmans, Weimar, Germany
<mailto:till...@gmx.net>, PGP key ID: 0xEE4EF72D (RSA)
Achim Denzl
> > 1. Zeichensätze
> > Suitcase läuft ganz ordentlich unter OS X, was allerdings fehlt ist
> > TypeReunion, also ein Utility, das im Zeichensatzmenü die Fonts nach
> > entsprechenden Gruppen gliedert. MenuFonts läuft IIRC auch nicht unter
> > OS X. Gibt's da zwischenzeitlich was?
>
> Ich glaube nicht, daß irgendwer meine Programme hackt und mir das Menü
> umbaut, wo's doch Speicherschutz geben soll..
Damit würde sich OS X aber für DTP-Anwendungen definitiv
disqualifizieren ;-(
Aber vielleicht muss das ja nicht auf einer per-Programm-Basis
geschehen, sondern könnte direkt ins System integriert werden. Soweit
meine Programmier-Kenntnisse reichen, wird's dann zwar keine Untermenüs
geben können, aber zumindest könnte das OS innerhalb der "flachen"
Fontliste zusammengehörende Zeichensätze direkt untereinander anordnen,
also z.B. so:
Arial
Arial Narrow
Helvetica
B Helvetica Bold
I Helvetica Italic
BI Helvetica BoldItalic
...
> > 5. Server
> > Wir haben ein paar Server mit relativ vielen ServerVolumes. Die Anbindung
> > mittels afp (tcp) klappt gut, nur das Automount über die Startobjekte
> > gefällt mir nicht, da beim login dann immer auch gleich die Fenster
> > geöffnet werden anstatt nur die Symbole auf dem Desktop anzuzeigen. Lösung
> > über AppleScript wäre wohl möglich, aber vielleicht gibt's was
> > Eleganteres?
>
> Mit Realbasic könnte ich dir sicher schnell was schreiben, was beim
> Starten in einer Textdatei server, name und passwort ausliesst und die
> Server mountet...
> (AFP Klassen im MBS Plugin)
Danke für Dein Angebot! Aber ich will Deine Zeit nicht mit so einem
Mini-Problem vergeuden, zumal ich sowas per AppleScript unter OS 9 auch
schon selber gebastelt hatte und das (glaube ich ;-) auch unter OS X
noch hinkriege. Falls nicht, ... ;-)
Ciao
Achim
Achim Denzl
> > Vielleicht weiß ja jemand (ohne erst Google zu bemühen ;-), ob und wann
> > Portierungen geplant sind: Adobe Distiller, Tailor, FontIncluder ...
>
> Zu Enfocus Tailor: Die Entwicklung ist mit der Version 2.0.8 zugunsten
> der PDF-Produkte (Pitstop usw.) eingestellt worden. Eine OS X-Version
> wird es nicht geben. Schade, vor allem weil Tailor ja von der
> NEXT-Plattform kam, allerdings dort die Display PS-Engine nutzen konnte.
Das ist wirklich Schade ;-(
Die wirklich guten OneVision-Produkte sind mir leider eine Hausnummer zu
teuer. Gibt's eigentlich außer Tailor eventuell noch einen anderen
"kleinen" PS-Editor, der OS X-fähig ist / sein wird?
Ciao
Acim
Thomas Kaiser
<news:1fp1npb.t0byfh1xj5po2N%use...@dtpd.com>:
> 1. Zeichensätze
> Suitcase läuft ganz ordentlich unter OS X,
Nahezu alle Tests, die ich bisher gelesen habe, sagen eigentlich was
anderes. Hast Du mal FontReserve näher auf den Zahn gefühlt?
> 2. Tastaturkürzel
> Viele Tastaturkürzel, die eigentlich für Funktionen im Anwendungsprogramm
> vorgesehen sind, werden unter OS X rigoros vom System bzw. Dock.app
> abgefangen (Apfel-Tab, Apfel-Alt-D,
Zumindest für letzteres scheint es Workarounds (im besten Sinn des Wortes)
zu geben, bspw. <http://raspberry.keywerks.de/german/index_de.html>
> 3. Native OS X Applications
> Es fehlen leider immer noch einige Key-Applikationen. Vielleicht weiß ja
> jemand (ohne erst Google zu bemühen ;-), ob und wann Portierungen
> geplant sind: Adobe Distiller, Tailor, FontIncluder ...
Zu Distiller: Der ist im Classic-Modus angeblich schneller als direkt unter
MacOS 9 betrieben (wohl weil das extrem lahme Filehandling von MacOS 9 in
der Classic-Umgebung nicht zum Tragen kommt?). Aussagen, ob der Distiller
evtl. mit Acrobat 6.x native sein wird, gibt es AFAIK keine verlässlichen
(vielleicht eine reine Abgrenzungsgeschichte zum Distiller Server, den Adobe
ja auch für einige UNIX-Plattformen anbietet?)
BTW: Kennst Du das "Create-PDF" Feature von Helios?
Zum Thema PostScript-Editor: Das Ganze war ja schon immer eine
anachronistische Aufgabenstellung, aus einem PostScript Stream (also eine
aufeinander aufbauende, kontinuierliche Seitenbeschreibung in Form eines
Programms) ein editierbares Graphikformat zu machen. Spätestens seitdem PDF
insofern erwachsen ist, als es alle für PrePress wichtigen Funktionalitäten
transportieren kann, macht es überhaupt keinen Sinn mehr, da PDF ganz im
Unterschied zu PostScript tatsächlich ein Graphikformat ist aber netterweise
nahezu 1:1 dasselbe graphische Modell wie PostScript verwendet.
Nur mit PDF ist es möglich, Änderungen frei auf Objektebene anzugehen; bei
PostScript musste immer zuerst in ein (proprietäres) Zwischenformat
gewandelt (also interpretiert durch ein RIP) und anschl. wieder in PS
exportiert werden (was manche nicht müde werden, als Feature zu verkaufen)
Ich würde mich an Deiner Stelle damit abfinden, daß es sinnvollere
technische Alternativen gibt...
> 4. PrintCenter
> Fast alle unsere Drucker/Belichter/Spooler werden mit PAP angesprochen.
> Soweit alles OK.
Naja, jetzt unter MacOS X ja nun wirklich nicht mehr. Daß Du keine PS-Jobs
mit mehr als 2 GByte mehr ausgeben kannst, ist bekannt? Daß das MacOS X
(10.2) eigene Spoolsystem nicht mehr wie unter MacOS 9 unter Umgehung des
Hintergrunddrucks *direkt* auf ein RIP drucken konnte, ohne ein einziges
Byte temporärer Daten auf dem Mac zwischenzuspeichern sondern grundsätzlich
in eine temporäre Datei druckt, diese Datei dann erneut in das Spoolsystem
*kopiert* (zwei temporäre Dateien je Druckjob!) und dann erst via PAP
gedruckt wird?
Mit MacOS X 10.2 hat Apple erstaunlicherweise wieder Argumente für die
traditionelle Funktionalität von OPI (also den reinen Grob-/Feinbild
Austausch) nachgelegt...
> Allerdings macht sich bei knapp zwei Dutzend Queues das Fehlen der
> Schreibtischdrucker-Symbole schon deutlich negativ bemerkbar;
Wieso? Für was verwendet Ihr die?
> das PrintCenter ist IMHO kein brauchbarer Ersatz, um schnell zwischen
> Druckern umzuschalten
Das kann man doch in den Drucken-Dialogen der Programme?
> und um alle Drucker gleichzeitig im Blick zu haben.
Ah, verstehe... Du druckst anscheinend nicht per Printserver sondern direkt
auf die einzelnen Geräte. Naja, ich finde die Variante mit Printserver aus
administrativen Gründen zigfach besser, insofern finde ich das absolut
verschmerzbar.
> Auch das Argument, dass man ja jetzt alle Drucker im Drucken-Dialog der
> Applikation auswählen könne, ist keine wirkliche Hilfe.
Wieso (ernsthaft)?
> Außerdem kann ich IIRC im PrintCenter keinen verbindungslosen Drucker
> zum Sichern einer Postscript-Datei anlegen, was die Zusammenarbeit mit
> Distiller-Hotfoldern ebenfalls erschwert. Irgendwelche Ideen?
Dem kann man relativ leicht abhelfen, indem man einfach ein neues "Backend"
in CUPS integriert, das eben in Dateien druckt. Ein solches Backend kann ein
simples Shellskript sein, das den Jobnamen extrahiert und den PS-Job in ein
Verzeichnis unter genau diesem Namen abspeichert (und dabei natürlich noch
auf Feinheiten wie Encoding-Konvertierungen und Überschreiben von PS-Dateien
gleichen Namens, etc. achtet). Ich habe mit derlei mal angefangen (für
Netatalk und Helios), allerdings mit zum Teil anderer Ausrichtung:
<http://users.phg-online.de/tk/netatalk/scripts/>
Eigentlich müsste man nur die print-to-file (das macht, was Du willst) und
print-to-pdf (wegen CUPS Backend Tauglichkeit) Funktionalität "mergen"...
> 5. Server
> Wir haben ein paar Server mit relativ vielen ServerVolumes. Die
> Anbindung mittels afp (tcp) klappt gut, nur das Automount über die
> Startobjekte gefällt mir nicht, da beim login dann immer auch gleich die
> Fenster geöffnet werden anstatt nur die Symbole auf dem Desktop
> anzuzeigen. Lösung über AppleScript wäre wohl möglich, aber vielleicht
> gibt's was Eleganteres?
In dcsm.lokale-netze wurde berichtet, das das Verhalten mit den sich
öffnenden Fenstern unterbleibt, wenn man einfach AFP-URLs in den
Startobjekten benutzt (ist eh viel simpler als AppleScript zu bemühen)
Gruss,
Thomas
Dirk Taggesell
> 3. Native OS X Applications
> Es fehlen leider immer noch einige Key-Applikationen. Vielleicht weiß ja
> jemand (ohne erst Google zu bemühen ;-), ob und wann Portierungen
> geplant sind: Adobe Distiller, Tailor, FontIncluder ...
Der neueste Distiller (per Update von der Adobe-Website geholt) scheint
Native-X zu sein. Eventuell karbonisiert, es wird jedenfalls kein Classic
mehr geladen.
--
mit freundlichen Grüßen
Dirk Taggesell
Peter Heilingbrunner
Dirk Taggesell <di...@taggesell.de> wrote:
> Der neueste Distiller (per Update von der Adobe-Website geholt) scheint
> Native-X zu sein. Eventuell karbonisiert, es wird jedenfalls kein Classic
> mehr geladen.
Ich finde bei Adobe nichts dergleichen. URL?
Grüße,
Peter
Michael Artz
> > Außerdem kann ich IIRC im PrintCenter keinen verbindungslosen Drucker
> > zum Sichern einer Postscript-Datei anlegen, was die Zusammenarbeit mit
> > Distiller-Hotfoldern ebenfalls erschwert. Irgendwelche Ideen?
>
> Dem kann man relativ leicht abhelfen, indem man einfach ein neues "Backend"
> in CUPS integriert, das eben in Dateien druckt. Ein solches Backend kann ein
> simples Shellskript sein, das den Jobnamen extrahiert und den PS-Job in ein
> Verzeichnis unter genau diesem Namen abspeichert (und dabei natürlich noch
> auf Feinheiten wie Encoding-Konvertierungen und Überschreiben von PS-Dateien
> gleichen Namens, etc. achtet). Ich habe mit derlei mal angefangen (für
> Netatalk und Helios), allerdings mit zum Teil anderer Ausrichtung:
>
> <http://users.phg-online.de/tk/netatalk/scripts/>
>
> Eigentlich müsste man nur die print-to-file (das macht, was Du willst) und
> print-to-pdf (wegen CUPS Backend Tauglichkeit) Funktionalität "mergen"...
Hm, da klinke ich mich jetzt aber mal ein:
Reines PostScript (wenn auch nur ausschließlich Level 3) über einen
Druckertreiber zu erzeugen ist doch auch unter OS X kein Problem. Im
Druckdialog unter "Output Options" statt 'PDF' 'PostScript' auswählen,
abspeichern, fertig.
Was mich viel mehr nervt ist, daß man keine EPS mehr direkt aus dem
Druckertreiber erzeugen kann. Aber das ist eine andere Geschichte.
Michael
--
REALITY.SYS corrupt. Reboot Universe? (y/n)
Bugreports to negmNGzhrafgre.qr
Thomas Kaiser
<news:1fp34du.saucfsnw9bysN%use...@artz-net.de>:
> Reines PostScript (wenn auch nur ausschließlich Level 3)
Es geht mit Quartz auch Level 2; das hängt von der für diesen Drucker
verwendeten PPD (Druckerbeschreibungsdatei) ab.
Wenn die Anwendung den PS-Code selbst erzeugt (und dann CUPS-seitig der
pictwpstops und nicht der cgpdftops Filter zum Einsatz kommt) sollte auch
Level 1 möglich sein. Aber wer will das heutzutage schon noch?
> über einen Druckertreiber zu erzeugen ist doch auch unter OS X kein Problem.
> Im Druckdialog unter "Output Options" statt 'PDF' 'PostScript' auswählen,
> abspeichern, fertig.
Für das gelegentliche Erzeugen von PS-Dateien für einen bestimmten Typ
Ausgabegerät sicher eine akzeptable Lösung.
Die Anforderungen sind aber vielschichtiger:
- Zum einen bestimmt die verwendete PPD, was für PS-Code erstellt wird
(PostScript Level, Farb- oder Graustufengerät, welche Schriften hat der
Drucker eingebaut, etc.) und welche druckerspezifischen Funktionen
bereitstehen (Duplexeinheit, mehrere Schächte für verschiedene
Papiersorten). Darüberhinaus kann in der PPD auch noch PostScript-Code
stecken, der beim Erzeugen des PS-Files eingebettet werden muß
--> welche PPD genommen wird, ist in professionellen Umgebungen verdammt
wichtig
- Entweder man hangelt sich jedes mal durch die ganzen Menüs durch für die
*druckerspezifischen* Einstellungen (so ja auch beispielsweise der Punkt
"Ausgabeoptionen", der es erst ermöglicht, überhaupt in eine PS-Datei zu
drucken) oder man speichert diese Sachen als "Einstellung", die man dann
in der Einstellungen-Liste auswählen kann. Dumm nur, daß das, was man in
den "Einstellungen" speichert nicht auch den "Drucker" beinhaltet. D.h.
um mit diesen "Einstellungen" überhaupt arbeiten zu können, muß auch noch
immer parallel der richtige "Drucker" ausgewählt sein (!), denn die
verwendete PPD wird der Druckerkonfiguration entnommen (und an der Stelle
kann es sein, daß die "Einstellungen" nichts mehr mit dem ursprünglichen
Ziel zu tun haben, da bspw. in der Druckerliste von einem A3-Farblaser mit
5 Eingabefächern auf einen simplen s/w A4-Tintenspritzer gewechselt wurde)
--> "Einstellungen" und "Drucker" müssen immer zueinander passen, was
spätestens bei zwei Druckern (aka zu verwendenden PPDs) zu einer nicht
zu unterschätzenden Fehlerquelle mutiert! Noch schlimmer, wenn man
ganz auf die "Einstellungen" verzichtet und manuell den Kram
konfigurieren will.
Beide Probleme könnten eben ganz bequem durch einen derartigen "in Datei
drucken" Mechanismus -- implementiert als CUPS-Backend -- gelöst werden.
Einfach im PrintCenter mit gedrückter [alt]-Taste auf "Hinzufügen" klicken,
eine PPD auswählen und fortan kann man da direkt reindrucken, ohne sich um
obiges Gedanken zu machen. Allerdings wäre dazu ein entsprechendes Backend
noch einigermassen aufzubohren, damit man alle Einstellungen (bspw. wohin
sichern?) auch wirklich bequem per PrintCenter einstellen kann.
Es macht zwar einigermassen Spaß in der Hinsicht mit CUPS und dem
interaktiven Ermitteln/Weitergeben von Backend-Fähigkeiten zu spielen.
Allerdings bin ich als klassischer Printserver-Verfechter eher bereit, die
Mechanismen für gscheide Server zu implementieren als dezentral für alle
Clients (Stichwort Administration des Ganzen)
> Was mich viel mehr nervt ist, daß man keine EPS mehr direkt aus dem
> Druckertreiber erzeugen kann. Aber das ist eine andere Geschichte.
Yo. Wobei Programme, die PrePress-Output erzeugen, normalerweise eine
fortgeschrittenere EPS-Export Möglichkeit beinhalten (außer... äh... Quark
Xpress) und man andererseits aus den via Quartz erzeugten PDFs mittels bspw.
GhostScript wohl auch EPS erzeugen können sollte ("können", "sollte" -- Du
siehst, daß ich es noch nicht probiert habe? Ich benutze in solchen
Situationen das Helios' pdftoeps, das in vielerlei Hinsicht überlegen ist)
Gruss,
Thomas
Michael Artz
> > Reines PostScript (wenn auch nur ausschließlich Level 3)
>
> Es geht mit Quartz auch Level 2; das hängt von der für diesen Drucker
> verwendeten PPD (Druckerbeschreibungsdatei) ab.
Stimmt. Ich hatte gerade nur zwei verschiedene PPDs im PrintCenter und
die waren beide von ziemlich neuen HP Color Lasern. Hab's gerade mal mit
einem älterne PPD für eine Lino ausprobiert und raus kam Level 2.
> > über einen Druckertreiber zu erzeugen ist doch auch unter OS X kein Problem.
> > Im Druckdialog unter "Output Options" statt 'PDF' 'PostScript' auswählen,
> > abspeichern, fertig.
>
> Für das gelegentliche Erzeugen von PS-Dateien für einen bestimmten Typ
> Ausgabegerät sicher eine akzeptable Lösung.
>
> Die Anforderungen sind aber vielschichtiger:
>
> [sehr viel richtiges zum Thema, wie man sich durch die Wahl des falschen PPDs
> einen Druckjob ordentlich versauen kann und wie man das umgehen kann und muß]
> Beide Probleme könnten eben ganz bequem durch einen derartigen "in Datei
> drucken" Mechanismus -- implementiert als CUPS-Backend -- gelöst werden.
> Einfach im PrintCenter mit gedrückter [alt]-Taste auf "Hinzufügen" klicken,
> eine PPD auswählen und fortan kann man da direkt reindrucken, ohne sich um
> obiges Gedanken zu machen. Allerdings wäre dazu ein entsprechendes Backend
> noch einigermassen aufzubohren, damit man alle Einstellungen (bspw. wohin
> sichern?) auch wirklich bequem per PrintCenter einstellen kann.
Ähem, den Trick mit ALT kannte ich ja schon, aber wie legen ich denn da
einen Drucker an, der nur in eine Datei druckt. Ich hab's mit einem LPR
Printer versucht, PPD ausgewählt und Device auf
'file://localhost/Users/michael/Desktop/' gesetzt. Jetzt habe ich zwar
einen neuen Drucker installiert, aber die Pfadangabe wird ignoriert.
Schade. Geht das auch eleganter?
> > Was mich viel mehr nervt ist, daß man keine EPS mehr direkt aus dem
> > Druckertreiber erzeugen kann. Aber das ist eine andere Geschichte.
>
> Yo. Wobei Programme, die PrePress-Output erzeugen, normalerweise eine
> fortgeschrittenere EPS-Export Möglichkeit beinhalten (außer... äh... Quark
> Xpress) und man andererseits aus den via Quartz erzeugten PDFs mittels bspw.
> GhostScript wohl auch EPS erzeugen können sollte ("können", "sollte" -- Du
> siehst, daß ich es noch nicht probiert habe? Ich benutze in solchen
> Situationen das Helios' pdftoeps, das in vielerlei Hinsicht überlegen ist)
Klar, Freehand und Konsorten können auch EPS. Aber hast du mal versucht,
eine Tabelle, die aus der Buchhaltung im (schauder) Excel-Format
eintrudelt, so aufzubereiten, daß sie auch in Quark oder InDesign
vernünftig plazierbar ist. Da bleibt nicht viel außer EPS (na, in
InDesign vielleicht auch PDF, aber so toll ist das auch nicht).
Danke für die Tipps (hoffentlich kriegt der OP die auch mit ;-))
Thomas Kaiser
<news:1fp3s8o.ng4ipk108pnuoN%use...@artz-net.de>:
> Ähem, den Trick mit ALT kannte ich ja schon,
Der dient ja auch nur dazu, nicht "authorisierte" Backends ebenfalls via
PrintCenter konfigurieren zu dürfen :-)
> aber wie legen ich denn da einen Drucker an, der nur in eine Datei druckt.
Da brauchst Du halt ein Backend, welches das intelligent umsetzt, denn der
"billige Trick" mit LPR an localhost...
> Ich hab's mit einem LPR Printer versucht, PPD ausgewählt und Device auf
> 'file://localhost/Users/michael/Desktop/' gesetzt.
...sorgt ja nur dafür, daß Du einen "verbindungslosen Drucker", wie es der
OP so schön formulierte, durch die Hintertür erzeugt hast. Den Druckjob
musst Du jetzt immer noch per "Sichern als PS-Datei" manuell in ein PS-File
umbiegen.
> Jetzt habe ich zwar einen neuen Drucker installiert, aber die Pfadangabe wird
> ignoriert. Schade. Geht das auch eleganter?
Ja. Und da bekanntlich viele Wege nach Rom führen, nicht nur einen.
Die Crux an der Geschichte ist, daß wenn man das alles per PrintCenter
machen will, man das eben nicht über einen "Ordner auswählen" Dialog machen
kann, denn konkret macht das PrintCenter als grafisches Frontend für CUPS
nur folgendes:
Es befrägt das CUPS Backend nach seinen Fähigkeiten und dieses antwortet
einmal generisch mit bspw.
direct file "Unknown" "In Datei drucken"
[1] und kann dann noch auflisten, welche Ablageorte es schon kennt und diese
dann aufzählen, bspw.:
direct file "file://signa?sub=kaiser" "SignaStation für Kaiser"
direct file "file://signa?sub=artz" "Ausschiessjobs für Artz"
direct file "file://avantra_44?sub=eilt" "Avantra dringende Jobs"
direct file "file://distiller_5?sub=in&res=1200" "PDF LowRes, 1200 dpi"
Es könnten jetzt im PrintCenter eben schon "SignaStation für Kaiser" oder
"PDF LowRes, 1200 dpi", etc. als *Drucker* ausgewählt werden. Wenn anschl.
gedruckt wird, bekommt "unser" Backend als Kommandozeilenparameter dann auch
den Device-URI (bspw. eben "file://signa") und weitere Optionen wie
"sub=artz" oder auch "res=1200" als AFAIR Umgebungsvariable mit.
Es bleibt dann Aufgabe des Backends, diese Parameter korrekt auszuwerten und
den Job in den richtigen Ordner umzuleiten und bspw. noch die richtigen
Distiller Joboptions dem PS-Job mitzugeben, etc.
Erzeugen könnte das Backend diese Device-URIs nebst Beschreibung, indem per
Konvention ein Ordner "PS-Jobs" existiert, in dem bspw. die Unterordner
"signa", "avantra_44", "distiller_5", etc. angelegt sind und in jedem von
denen Unterordner (kaiser, artz, etc.) und darin wiederum kleine
Textdateien, die die Beschreibung beisteuern, rumliegen.
Das Admin-Manual (http://localhost:631/sam.html) ist sehr ausführlich und es
existieren massenhaft Skriptbeispiele für derlei Backends im Netz.
Problematisch sind lediglich noch so Dinge, wie Encoding-Konvertierung,
Verhindern des Überschreibens von bereits existierenden Dateien,
Restriktionen der Dateinamenslänge (wegen Distiller in Classic evtl.), etc.
Ich habe das zwar mal mit Shellskript-Methoden angefangen aber das führt
irgendwie in den Wald. Ein Bekannter von mir hat das ganze sauber in Perl
nachprogrammiert (ohne extrene Abhängigkeiten zu bspw. recode -- er löst
Encoding-Geschichten direkt in Perl), traut sich aber nicht an die
Öffentlichkeit :-(
D.h. also selber Basteln ;-) Aber die meisten Sachen kann man sich aus
anderen Skripts zusammentragen :-)
[keine EPS mehr direkt aus dem Druckertreiber erzeugen]
> Klar, Freehand und Konsorten können auch EPS. Aber hast du mal versucht,
> eine Tabelle, die aus der Buchhaltung im (schauder) Excel-Format
> eintrudelt, so aufzubereiten, daß sie auch in Quark oder InDesign
> vernünftig plazierbar ist.
Klar. Als ich noch im DTP-Tagesgeschäft war, waren wir eine der ersten
Anwender von PDF-Handshake (war um 1999 rum). So eine Tabelle wurde dann
einfach in PDF gewandelt (so kommt sie ja heute dank Quartz eh schon her)
und auf den Server geschoben. Das dort entstehende (EPS-)Grobbild wurde
eingebaut, gedruckt und nicht mehr drüber nachgedacht (denn die Technologie
auf dem Server kümmerte sich gleich noch um Farbraumtranformationen,
Vermeiden von Haarlinien und all die anderen Dinge, die beim EPS-Export aus
Office sowieso immer schief gehen). Technik ist dazu da, unauffällig und
perfekt zu funktionieren :-)
> Da bleibt nicht viel außer EPS (na, in InDesign vielleicht auch PDF, aber
> so toll ist das auch nicht).
Och, InDesign im Vergleich zu Illustrator ist wirklich nicht schlecht, wenn
es um PDF-Import geht, finde ich.
> Danke für die Tipps (hoffentlich kriegt der OP die auch mit ;-))
Ach, ich denke mal schon. Aber Achim ist im Druckvorstufen-Tagesgeschäft
beheimatet, d.h. der kommt nur zwischen 2:00 Uhr und 5:00 Uhr zu Freizeit --
kann also wohl mit 'ner Antwort dauern ;-)
Gruss,
Thomas
[1] "direct" meint, daß das "Device" lokal vorhanden ist, "file" ist der
URI-Typ, "Unknown" steht eben für die generelle Fähigkeit und "In Datei
drucken" ist die Beschreibung der Druckerart, wie sie dann auch im
PrintCenter/CUPS angezeigt wird.
Achim Denzl
...
> Problematisch sind lediglich noch so Dinge, wie Encoding-Konvertierung,
> Verhindern des Überschreibens von bereits existierenden Dateien,
> Restriktionen der Dateinamenslänge (wegen Distiller in Classic evtl.), etc.
> Ich habe das zwar mal mit Shellskript-Methoden angefangen aber das führt
> irgendwie in den Wald. Ein Bekannter von mir hat das ganze sauber in Perl
> nachprogrammiert (ohne extrene Abhängigkeiten zu bspw. recode -- er löst
> Encoding-Geschichten direkt in Perl), traut sich aber nicht an die
> Öffentlichkeit :-(
>
> D.h. also selber Basteln ;-) Aber die meisten Sachen kann man sich aus
> anderen Skripts zusammentragen :-)
OS X ist manchmal wie Windows: Ohne diesen Bastelspaß wäre der
Freizeitüberschuss beinahe unerträglich ;-)
> > Danke für die Tipps (hoffentlich kriegt der OP die auch mit ;-))
>
> Ach, ich denke mal schon. Aber Achim ist im Druckvorstufen-Tagesgeschäft
> beheimatet, d.h. der kommt nur zwischen 2:00 Uhr und 5:00 Uhr zu Freizeit --
> kann also wohl mit 'ner Antwort dauern ;-)
Whoops, da bin ja heute glatt mal zu früh dran ;-)
Ciao
Achim
Achim Denzl
> > 1. Zeichensätze
> > Suitcase läuft ganz ordentlich unter OS X,
>
> Nahezu alle Tests, die ich bisher gelesen habe, sagen eigentlich was
> anderes. Hast Du mal FontReserve näher auf den Zahn gefühlt?
Bis jetzt noch nicht. Hier auf meinem Privat-Rechner (unter OS X,
looogisch) klappt's gut mit Suitcase. Ob sich das 1:1 auf den
Arbeitsalltag übertragen läßt, wird sich zeigen ...
> > 2. Tastaturkürzel
> > Viele Tastaturkürzel, die eigentlich für Funktionen im Anwendungsprogramm
> > vorgesehen sind, werden unter OS X rigoros vom System bzw. Dock.app
> > abgefangen (Apfel-Tab, Apfel-Alt-D,
>
> Zumindest für letzteres scheint es Workarounds (im besten Sinn des Wortes)
> zu geben, bspw. <http://raspberry.keywerks.de/german/index_de.html>
Hab' ich mir schon angeschaut. Leider ist Apfel-Alt-D das
Tastaturkürzel, das mich am wenigsten stört. Apfel-(Shift)-Tab ist die
Crux, weil ich das als XPressler alle paar Sekunden brauche und dann
jedesmal im nächten/vorhergehenden Programm lande ;-(
Allerdings wäre ich auch für ein paar Tipps dankbar, in welchen Untiefen
von OS X sich diese Kürzel verbergen (bestimmt bloß wieder irgendeine
Textdatei, supersimpel eigentlich ;-). Es scheint in erster Linie was
mit Dock.app zu tun zu haben, wenn ich das abschieße, geht's. Und was
für Apfel-Alt-D gilt, sollte doch auch für Apfel-Tab gehen, oder?
> > 3. Native OS X Applications
> > Es fehlen leider immer noch einige Key-Applikationen. Vielleicht weiß ja
> > jemand (ohne erst Google zu bemühen ;-), ob und wann Portierungen
> > geplant sind: Adobe Distiller, Tailor, FontIncluder ...
> Zum Thema PostScript-Editor: Das Ganze war ja schon immer eine
[SNIP]
> Ich würde mich an Deiner Stelle damit abfinden, daß es sinnvollere
> technische Alternativen gibt...
Und welche? Der Umweg über PDF ist IMHO eben nur ein Umweg. Mal ein
Beispiel: Wir kriegen von einer anderen Zeitung eine fertige Anzeige für
eine unserer Publikationen. Da die anderen mit CorelDraw auf PC
arbeiten, ist es meistens eine EPS-Datei. Nun will der Kunde noch
schnell einen Preis geändert haben ...
Was bisher geschah: EPS in Tailor öffnen, Preis ausbessern, sichern
Was in Zukunft geschieht: EPS mit Distiller in PDF konvertieren, PDF in
Acrobat öffnen, Preis ausbessern, PDF als EPS exportieren
Das dauert um Welten länger als der direkte Weg, zumal Acrobat
insbesondere beim Editieren von Texten schnarchlangsam ist.
Ebenso häufig kommt es vor, dass wir nur Teile des fertigen EPS (1 x
Foto, 1 x Logobalken, 1 x Rahmen) benötigen. In Tailor kann ich mir die
einzelnen Elemente gezielt als Einzel-Elemente raussichern und dann
später in Quark neu zusammensetzen. Das geht in Acrobat in der Form
überhaupt nicht, IIRC.
> > 4. PrintCenter
> > Fast alle unsere Drucker/Belichter/Spooler werden mit PAP angesprochen.
> > Soweit alles OK.
>
> Naja, jetzt unter MacOS X ja nun wirklich nicht mehr. Daß Du keine PS-Jobs
> mit mehr als 2 GByte mehr ausgeben kannst, ist bekannt? Daß das MacOS X
> (10.2) eigene Spoolsystem nicht mehr wie unter MacOS 9 unter Umgehung des
> Hintergrunddrucks *direkt* auf ein RIP drucken konnte, ohne ein einziges
> Byte temporärer Daten auf dem Mac zwischenzuspeichern sondern grundsätzlich
> in eine temporäre Datei druckt, diese Datei dann erneut in das Spoolsystem
> *kopiert* (zwei temporäre Dateien je Druckjob!) und dann erst via PAP
> gedruckt wird?
Ok, ok, ich war ja bloß froh, dass PAP überhaupt unterstützt wird ;-)
> > Allerdings macht sich bei knapp zwei Dutzend Queues das Fehlen der
> > Schreibtischdrucker-Symbole schon deutlich negativ bemerkbar;
>
> Wieso? Für was verwendet Ihr die?
Belichter; Belichter-Spooler; 6 x Digitalproof (3 Papiersorten, jeweils
mit und ohne Cropmarks); A4-Laser; A3-Laser; Belichter via PS-Datei,
Belichter via PS-Datei mit fixen 1800 dpi; diverse PS-Queues, die in
verschiedenen Distiller-Hotfoldern landen ...
> Ah, verstehe... Du druckst anscheinend nicht per Printserver sondern direkt
> auf die einzelnen Geräte. Naja, ich finde die Variante mit Printserver aus
> administrativen Gründen zigfach besser, insofern finde ich das absolut
> verschmerzbar.
Teils, teils. Manche Jobs laufen über den ASIP-Spooler, manche direkt
bzw. über PS-Datei mit Hotfolder.
> > Auch das Argument, dass man ja jetzt alle Drucker im Drucken-Dialog der
> > Applikation auswählen könne, ist keine wirkliche Hilfe.
>
> Wieso (ernsthaft)?
Da kann ich Dir jetzt nur subjektiv antworten: Diese Funktionalität
gab's auch schon unter OS < X, allerdings erwies sich das Umschalten
innerhalb der Application oftmals als fehlerträchtig (PPDs, Schriften).
Zum anderen kriege ich den Drucken-Dialog selten zu Gesicht, die meisten
unserer Dokumente sind bereits grundsätzlich richtig eingestellt, so
dass ein blindes Apfel-P <RETURN> meistens genügt. Und ein kurzer Blick
auf den Zweitmonitor verrät sofort, wo der Druckjob hingeht ...
Und zudem ist es in QXP noch umständlicher, da ich aus dem
Haupt-Druckdialog erst in ein weiteres Fenster wechseln muss, um den
Drucker zu ändern, was dann bei PS-File-Druckern wiederum dazu führt,
dass ich den Speicherort erneut händisch festlegen muss.
> > Außerdem kann ich IIRC im PrintCenter keinen verbindungslosen Drucker
> > zum Sichern einer Postscript-Datei anlegen, was die Zusammenarbeit mit
> > Distiller-Hotfoldern ebenfalls erschwert. Irgendwelche Ideen?
>
> Dem kann man relativ leicht abhelfen, indem man einfach ein neues "Backend"
> in CUPS integriert, das eben in Dateien druckt. Ein solches Backend kann ein
> simples Shellskript sein, das den Jobnamen extrahiert und den PS-Job in ein
> Verzeichnis unter genau diesem Namen abspeichert (und dabei natürlich noch
> auf Feinheiten wie Encoding-Konvertierungen und Überschreiben von PS-Dateien
> gleichen Namens, etc. achtet). Ich habe mit derlei mal angefangen (für
> Netatalk und Helios), allerdings mit zum Teil anderer Ausrichtung:
>
> <http://users.phg-online.de/tk/netatalk/scripts/>
>
> Eigentlich müsste man nur die print-to-file (das macht, was Du willst) und
> print-to-pdf (wegen CUPS Backend Tauglichkeit) Funktionalität "mergen"...
Ich persönlich beschäftige mich ja ganz gerne mit solchen Basteleien,
aber wirklich alltagstauglich ist das nicht. Zumal man ja auch
Mitarbeiter hat, die das (notfalls mit telefonischer Unterstützung) auch
alleine können sollten - und zwar ohne tiefergreifende UNIX-, CUPS- oder
Terminal-Kenntnisse.
> > 5. Server
> > Wir haben ein paar Server mit relativ vielen ServerVolumes. Die
> > Anbindung mittels afp (tcp) klappt gut, nur das Automount über die
> > Startobjekte gefällt mir nicht, da beim login dann immer auch gleich die
> > Fenster geöffnet werden anstatt nur die Symbole auf dem Desktop
> > anzuzeigen. Lösung über AppleScript wäre wohl möglich, aber vielleicht
> > gibt's was Eleganteres?
>
> In dcsm.lokale-netze wurde berichtet, das das Verhalten mit den sich
> öffnenden Fenstern unterbleibt, wenn man einfach AFP-URLs in den
> Startobjekten benutzt (ist eh viel simpler als AppleScript zu bemühen)
Das klingt gut, bei Gelegenheit mal testen ...
Ciao
Achim
Andreas Mattern
> Und welche? Der Umweg über PDF ist IMHO eben nur ein Umweg. Mal ein
> Beispiel: Wir kriegen von einer anderen Zeitung eine fertige Anzeige für
> eine unserer Publikationen. Da die anderen mit CorelDraw auf PC
> arbeiten, ist es meistens eine EPS-Datei. Nun will der Kunde noch
> schnell einen Preis geändert haben ...
Wenn es nur darum geht, das kann man mit vi im postscript-code von Hand
editieren! ;)
--
Andreas Mattern andreas.mattern at ikm.uni-karlsruhe.de
Institut fuer Keramik im Maschinenbau Uni Karlsruhe
There are 10 kinds of people in the world: those who understand binary,
and those who don't.
Thomas Kaiser
<news:1fp3zr8.wup6da1vnt648N%use...@dtpd.com>:
[PostScript-Editor]
> Der Umweg über PDF ist IMHO eben nur ein Umweg.
So unterschiedlich sind die Geschmäcker. Für mich ist PDF seit geraumer Zeit
das Ziel und nicht Zwischenstation :-)
> Mal ein Beispiel: Wir kriegen von einer anderen Zeitung eine fertige Anzeige
> für eine unserer Publikationen. Da die anderen mit CorelDraw auf PC arbeiten,
> ist es meistens eine EPS-Datei.
Ich weigere mich seit Jahren, sowas anzunehmen. Der Kunde darf ein PDF
machen, das man dann auch effizient einem Preflight zuführen kann.
> Nun will der Kunde noch schnell einen Preis geändert haben ...
Yo, dann darf er sein CorelDraw erneut bemühen und abermals ein PDF
schicken.
Vielleicht bin ich da aus meiner "aktiven" Zeit noch zu sehr von zwei Sachen
geprägt: Kleinkundenausmistung einerseits und andererseits Schaffen von
Produktionssicherheit (in Form von Standards und Automatismen)
Ich würde keine EPS annehmen, weil in einem EPS prinzipiell jeder Müll
drinstecken kann, der eben in PostScript möglich ist. Bei PDF sieht es nicht
gar so schlimm aus, v.a. kann man die Kunden dazu bringen, daß sie bei sich
bereits einen Preflight machen, d.h. viel Schrott gar nicht erst zur
Auslieferung kommt.
Und der anderen Geschichte mit den "Last-Minute" Korrekturen stehe ich auch
eher skeptisch gegenüber, da es irgendwo auch um die Haftung für Fehler
geht. Wer zeichnet in welcher Phase des Produktionsprozesses für was
verantwortlich?
Es wird immer gerne vergessen, daß zwischen dem Layouten eines
Seitenabbildes und der Darstellung auf dem bzw. im finalen Medium nicht nur
ein Dateiformat (PDF bspw.) oder ein Programm (EPS bzw. PostScript) sondern
eben auch die Interpretation des Informationsträgers steht. Und was alleine
dabei schief gehen kann, könnte ganze Bücher füllen.
Ich war neulich bei der FOGRA und habe denen ein paar Sachen auf den Server
installiert und dabei auch ein wenig über das Thema geplauscht (die sitzen
ja an der Quelle, da sie in D die Gutachten schreiben "dürfen", wenn sich
zwei streiten, wer das Druckergebnis verbockt, die Umlaute gekillt, das Bild
verschwinden hat lassen). Interessante Geschichten... Wird anscheinend dazu
führen, daß die FOGRA eine neue Studie rausgibt, in der eben auch Stellung
dazu bezogen wird, *wie* der richtige Workflow aussehen sollte, um
Überraschungen durch Dateiformat bzw. viel schlimmer die unterschiedlich
ausfallende Interpretation desselben so weit wie möglich auszuschließen.
Der Autor der Studie wendet sich allerdings wegen der Aussichtslosigkeit des
Ganzen schon jetzt dem Zynismus zu ;-)
> Was bisher geschah: EPS in Tailor öffnen, Preis ausbessern, sichern
> Was in Zukunft geschieht: EPS mit Distiller in PDF konvertieren, PDF in
> Acrobat öffnen, Preis ausbessern, PDF als EPS exportieren
Wie gesagt: Mein Weg --> PDF annehmen/preflighten, PDF editieren, PDF
entweder auf Server klatschen (wenn Anzeige platziert werden soll -->
Grobbild einbauen) oder per Hotfolder oder Ausgabe-PlugIn in Acrobat direkt
ausgeben.
> Das dauert um Welten länger als der direkte Weg, zumal Acrobat
> insbesondere beim Editieren von Texten schnarchlangsam ist.
Echt? Du destillierst aber nicht zufällig mit Joboptions bzw. Schriftarten,
die zu Font-Untergruppen führen?
> Ebenso häufig kommt es vor, dass wir nur Teile des fertigen EPS (1 x
> Foto, 1 x Logobalken, 1 x Rahmen) benötigen. In Tailor kann ich mir die
> einzelnen Elemente gezielt als Einzel-Elemente raussichern
Bei Bildern geht das alleine schon mit der in Acrobat eingebauten TouchUp
Funktion -- sehr bequem, wissen nur die wenigsten
> und dann später in Quark neu zusammensetzen. Das geht in Acrobat in der
> Form überhaupt nicht, IIRC.
Aber in Illustrator bspw. Das ist zwar *definitiv* kein vollwertiger
PDF-Editor (sagt auch Adobe selbst nicht) aber wenn man die Grenzen kennt,
kann man derlei Spaß (also das Neuzambauen von Logos oder das Extrahieren
von Elementen) damit weitestgehend problemlos machen...
[Warum ist Fehlen der "Schreibtischdrucker" ein Manko?]
> Da kann ich Dir jetzt nur subjektiv antworten: Diese Funktionalität
> gab's auch schon unter OS < X, allerdings erwies sich das Umschalten
> innerhalb der Application oftmals als fehlerträchtig (PPDs, Schriften).
Das wäre mir allerdings neu...
> Zum anderen kriege ich den Drucken-Dialog selten zu Gesicht, die meisten
> unserer Dokumente sind bereits grundsätzlich richtig eingestellt, so
> dass ein blindes Apfel-P <RETURN> meistens genügt.
Wow, "no risk, no fun" in Reinstform :-)
> Und ein kurzer Blick auf den Zweitmonitor verrät sofort, wo der Druckjob
> hingeht ...
Und ob er auch richtig eingestellt ist?
> Und zudem ist es in QXP noch umständlicher, da ich aus dem Haupt-Druckdialog
> erst in ein weiteres Fenster wechseln muss, um den Drucker zu ändern,
Echt? Ich habe das zu meiner aktiven Zeit glaube ich über das Skript-Menü
gemacht bzw. immer per AppleScript die Einstellungen vorgenommen. Waren aber
seltens wechselnde Objekte sondern meistens Periodika bzw. Kataloge, bei
denen man mit einem festen Set von "Drucksettings" arbeiten konnte.
BTW: Kennst Du Made-to-Print und Autopilot von Callas?
> was dann bei PS-File-Druckern wiederum dazu führt, dass ich den Speicherort
> erneut händisch festlegen muss.
Ein guter Printserver wirkt oftmals Wunder ;-)
[verbindungsloser Drucker in Datei]
>> Eigentlich müsste man nur die print-to-file (das macht, was Du willst) und
>> print-to-pdf (wegen CUPS Backend Tauglichkeit) Funktionalität "mergen"...
>
> Ich persönlich beschäftige mich ja ganz gerne mit solchen Basteleien,
> aber wirklich alltagstauglich ist das nicht.
Doch, doch. Man muß sowas halt eben einmal inkl. Fehlerbehandlung und Testen
fertig programmieren. Das nebenbei für die Allgemeinheit zu machen, dazu
habe ich grad weder Zeit noch Lust.
Und kommerziell macht es einfach irgendwie keinen Sinn, denn die, denen es
was bringen würde, sind mit vernünftigen Server-basierten Lösungen mehrfach
besser beraten.
> Zumal man ja auch Mitarbeiter hat, die das (notfalls mit telefonischer
> Unterstützung) auch alleine können sollten - und zwar ohne tiefergreifende
> UNIX-, CUPS- oder Terminal-Kenntnisse.
Genau. Und exakt das ist möglich. Auch trotz Einsatz von Shellskripts und
Kommandozeile. Die Tatsache, daß ein Mac unter MacOS X booten kann (egal wie
wenig Sachverstand vor dem Bildschirm sitzt), beweist das :-)
Ich spreche ja nicht davon, daß die Leute in Terminal.app werkeln sollen,
sondern daß das CUPS-Backend den Job macht und via PrintCenter mit den
Benutzern kommuniziert. Nur weil kryptisch zu bedienbare Technologien im
Einsatz sind, heisst das doch noch lange nicht, daß der Benutzer was davon
mitbekommen muß, oder?
Gruss,
Thomas
Thomas Kaiser
<news:b0iuvg$qr2$2...@news.rz.uni-karlsruhe.de>:
> Achim Denzl <use...@dtpd.com> wrote:
>> EPS-Datei. Nun will der Kunde noch schnell einen Preis geändert haben ...
>
> Wenn es nur darum geht, das kann man mit vi im postscript-code von Hand
> editieren! ;)
Wird aber spätestens dann schwierig, wenn man typographische Details
berücksichtigen muss (bspw. Unterschneidungen).
Gruss,
Thomas, der in grauer Vorzeit in PostScript Spoolfiles schon mit dem
Diskeditor noch Flecken in Bildern raus"retuschiert" hat ;-)
Thomas Jakobi
> > Wir haben ein paar Server mit relativ vielen ServerVolumes. Die
> > Anbindung mittels afp (tcp) klappt gut, nur das Automount über die
> > Startobjekte gefällt mir nicht, da beim login dann immer auch gleich die
> > Fenster geöffnet werden anstatt nur die Symbole auf dem Desktop
> > anzuzeigen.
> In dcsm.lokale-netze wurde berichtet, das das Verhalten mit den sich
> öffnenden Fenstern unterbleibt, wenn man einfach AFP-URLs in den
> Startobjekten benutzt
Ein anderer Weg wird hier beschrieben:
http://www.bombich.com/mactips/automount.html
Gruß
Jako
Achim Denzl
> [PostScript-Editor]
> > Der Umweg über PDF ist IMHO eben nur ein Umweg.
>
> So unterschiedlich sind die Geschmäcker. Für mich ist PDF seit geraumer Zeit
> das Ziel und nicht Zwischenstation :-)
Da gebe ich Dir grundsätzlich recht. Aber ebenso wie PS ist PDF ein
"Ziel"-Format, aber kein "Arbeits"-Format. Und genauso wenig, wie ich
jemals direkt in Postscript "gesetzt" habe, macht es IMHO Sinn, direkt
im PDF-Format zu arbeiten.
> > Mal ein Beispiel: Wir kriegen von einer anderen Zeitung eine fertige
> > Anzeige für eine unserer Publikationen. Da die anderen mit CorelDraw auf
> > PC arbeiten, ist es meistens eine EPS-Datei.
>
> Ich weigere mich seit Jahren, sowas anzunehmen. Der Kunde darf ein PDF
> machen, das man dann auch effizient einem Preflight zuführen kann.
Sorry, aber das sehe ich grundlegend anders. Wir sind ein
Mediendienstleister, und unsere Aufgabe ist es, dem Kunden die
größtmögliche Flexibilität bei der Verarbeitung _seiner_ Daten
entgegenzubringen. Schließlich ist genau das unser Job ;-)
Ich halte es für sehr bedenklich, dem Kunden zwingend eine Technik auf's
Auge zu drücken, die für den technischen Laien nur bedingt beherschbar
ist und deshalb ---> (*)
> > Nun will der Kunde noch schnell einen Preis geändert haben ...
>
> Yo, dann darf er sein CorelDraw erneut bemühen und abermals ein PDF
> schicken.
Kann er gerne, muss er aber nicht ...
>
> Vielleicht bin ich da aus meiner "aktiven" Zeit noch zu sehr von zwei Sachen
> geprägt: Kleinkundenausmistung einerseits und andererseits Schaffen von
> Produktionssicherheit (in Form von Standards und Automatismen)
(*) ---> die Produktionssicherheit eher gefährdet. Denn auch wenn ich
mir PDF im Gegensatz zu PS nett am Bildschirm anschauen kann, können die
internen Daten trotzdem ähnlich fehlerhaft sein wie bei einem PS-Job.
Und da helfen auch Preflight-Utilities nicht in jedem Fall weiter. Mir
ist es da allemal lieber, der Kunde schickt eine offene Quark-Datei, aus
der ich selbst ein sauberes EPS backen kann, als das er mir ein PDF
unterjubelt, das mir heimlich ein paar zusätzliche Farbauszüge aus dem
RIP quält o. ä.
> Ich würde keine EPS annehmen, weil in einem EPS prinzipiell jeder Müll
> drinstecken kann, der eben in PostScript möglich ist. Bei PDF sieht es nicht
> gar so schlimm aus, v.a. kann man die Kunden dazu bringen, daß sie bei sich
> bereits einen Preflight machen, d.h. viel Schrott gar nicht erst zur
> Auslieferung kommt.
Der gleiche Müll kann aber auch in einem PDF stecken, und
Preflight-Checking auf Kundenseite ist auch nicht der Weisheit letzter
Schluß. Ich kann ja kaum jedem, der bei einem unserer Verlags-Kunden
eine Anzeige aufgibt, eine Acrobat-Vollversion inklusive PitStop
schenken ...
> > Was bisher geschah: EPS in Tailor öffnen, Preis ausbessern, sichern
> > Was in Zukunft geschieht: EPS mit Distiller in PDF konvertieren, PDF in
> > Acrobat öffnen, Preis ausbessern, PDF als EPS exportieren
>
> Wie gesagt: Mein Weg --> PDF annehmen/preflighten, PDF editieren, PDF
> entweder auf Server klatschen (wenn Anzeige platziert werden soll -->
> Grobbild einbauen)
Das läßt sich sicher unter HELIOS alles wunderschön lösen. Aber nicht
jeder hat/braucht HELIOS. Und ich werde mir jetzt nicht extra HELIOS
zulegen, nur um Dinge, die ich unter OS 9 problemlos erledigen konnte,
auch mit OS X-Arbeitsplätzen wieder machen zu können.
> oder per Hotfolder oder Ausgabe-PlugIn in Acrobat direkt
> ausgeben.
Ok, das geht auch ohne HELIOS ;-)
> > Das dauert um Welten länger als der direkte Weg, zumal Acrobat
> > insbesondere beim Editieren von Texten schnarchlangsam ist.
>
> Echt? Du destillierst aber nicht zufällig mit Joboptions bzw. Schriftarten,
> die zu Font-Untergruppen führen?
Weiß ich jetzt nicht auswendig, werde ich aber morgen mal checken.
Interpretiere ich Deine Aussage richtig, dass es sinnvoller wäre,
_keine_ Untergruppen zu bilden?
> > Ebenso häufig kommt es vor, dass wir nur Teile des fertigen EPS (1 x
> > Foto, 1 x Logobalken, 1 x Rahmen) benötigen. In Tailor kann ich mir die
> > einzelnen Elemente gezielt als Einzel-Elemente raussichern
>
> Bei Bildern geht das alleine schon mit der in Acrobat eingebauten TouchUp
> Funktion -- sehr bequem, wissen nur die wenigsten
Doch, doch, weiß ich ;-)
Schwieriger wird's allerdings, wenn ich mehrere Elemente benötige (z. B.
Logoblock bestehend aus Firmenlogo, Rahmen und Adresszeile). In Tailor
aktiviere ich die Objekte, die ich benötige, und schreibe diese mit der
Option "Nur aktivierte Objekte" in ein neues EPS. In Acrobat gibt's
dafür AFAIK keine Möglichkeit
> > und dann später in Quark neu zusammensetzen. Das geht in Acrobat in der
> > Form überhaupt nicht, IIRC.
>
> Aber in Illustrator bspw. Das ist zwar *definitiv* kein vollwertiger
> PDF-Editor (sagt auch Adobe selbst nicht) aber wenn man die Grenzen kennt,
> kann man derlei Spaß (also das Neuzambauen von Logos oder das Extrahieren
> von Elementen) damit weitestgehend problemlos machen...
Das ist ja dann erst recht umständlich, noch ein Programm mehr
dazwischen ;-)
> [Warum ist Fehlen der "Schreibtischdrucker" ein Manko?]
> > Da kann ich Dir jetzt nur subjektiv antworten: Diese Funktionalität
> > gab's auch schon unter OS < X, allerdings erwies sich das Umschalten
> > innerhalb der Application oftmals als fehlerträchtig (PPDs, Schriften).
>
> Das wäre mir allerdings neu...
Ich weiss leider nicht mehr genau, wo das Problem lag, hatte das nur
noch irgendwie im Hinterkopf ...
> > Zum anderen kriege ich den Drucken-Dialog selten zu Gesicht, die meisten
> > unserer Dokumente sind bereits grundsätzlich richtig eingestellt, so
> > dass ein blindes Apfel-P <RETURN> meistens genügt.
>
> Wow, "no risk, no fun" in Reinstform :-)
Nö, einfach nur ordentliche Musterseiten ;-)
> > Und ein kurzer Blick auf den Zweitmonitor verrät sofort, wo der Druckjob
> > hingeht ...
>
> Und ob er auch richtig eingestellt ist?
Wieso? Drucker auswählen, PPD einstellen, Druckeroptionen festlegen,
fertig!
> > Und zudem ist es in QXP noch umständlicher, da ich aus dem Haupt-Druckdialog
> > erst in ein weiteres Fenster wechseln muss, um den Drucker zu ändern,
>
> Echt? Ich habe das zu meiner aktiven Zeit glaube ich über das Skript-Menü
> gemacht bzw. immer per AppleScript die Einstellungen vorgenommen. Waren aber
> seltens wechselnde Objekte sondern meistens Periodika bzw. Kataloge, bei
> denen man mit einem festen Set von "Drucksettings" arbeiten konnte.
Seit QXP 4 gibt es ja die Druckstile, damit geht das eh super einfach.
Leider kann man da nicht auch gleich den Drucker mitspeichern.
> BTW: Kennst Du Made-to-Print und Autopilot von Callas?
Vom Namen her, vielleicht auch schon mal eine Demo angeschaut. Erzähl'
mal ...
> > was dann bei PS-File-Druckern wiederum dazu führt, dass ich den Speicherort
> > erneut händisch festlegen muss.
>
> Ein guter Printserver wirkt oftmals Wunder ;-)
... insbesondere im Geldbeutel ;-)
> [verbindungsloser Drucker in Datei]
> >> Eigentlich müsste man nur die print-to-file (das macht, was Du willst) und
> >> print-to-pdf (wegen CUPS Backend Tauglichkeit) Funktionalität "mergen"...
> >
> > Ich persönlich beschäftige mich ja ganz gerne mit solchen Basteleien,
> > aber wirklich alltagstauglich ist das nicht.
>
> Doch, doch. Man muß sowas halt eben einmal inkl. Fehlerbehandlung und Testen
> fertig programmieren. Das nebenbei für die Allgemeinheit zu machen, dazu
> habe ich grad weder Zeit noch Lust.
>
> Und kommerziell macht es einfach irgendwie keinen Sinn, denn die, denen es
> was bringen würde, sind mit vernünftigen Server-basierten Lösungen mehrfach
> besser beraten.
Grundsätzlich ja, aber nicht immer ist es sinnvoll, das Ganze über den
Server zu jagen. Abgesehen davon ist es einfach nur ärgerlich, dass
vernünftige Funktionen, die im "alten" OS implementiert waren und auch
häufig genutzt wurden, und zudem in Mac OS X herstellerseitig ohne
großen Aufwand machbar wären, einfach unter den Tisch fallen - gerade
so, als ob der Mac noch nie für DTP eingesetzt worden wäre ...
> > Zumal man ja auch Mitarbeiter hat, die das (notfalls mit telefonischer
> > Unterstützung) auch alleine können sollten - und zwar ohne tiefergreifende
> > UNIX-, CUPS- oder Terminal-Kenntnisse.
>
> Genau. Und exakt das ist möglich. Auch trotz Einsatz von Shellskripts und
> Kommandozeile. Die Tatsache, daß ein Mac unter MacOS X booten kann (egal wie
> wenig Sachverstand vor dem Bildschirm sitzt), beweist das :-)
>
> Ich spreche ja nicht davon, daß die Leute in Terminal.app werkeln sollen,
> sondern daß das CUPS-Backend den Job macht und via PrintCenter mit den
> Benutzern kommuniziert. Nur weil kryptisch zu bedienbare Technologien im
> Einsatz sind, heisst das doch noch lange nicht, daß der Benutzer was davon
> mitbekommen muß, oder?
Wer A sagt, muss auch B sagen: Dann verrate doch mal, wie's geht ;-)
Thomas Kaiser
<news:1fp5ro4.9v0ioy1fyzwy8N%use...@dtpd.com>:
> ebenso wie PS ist PDF ein "Ziel"-Format, aber kein "Arbeits"-Format.
PostScript ist gar kein Format sondern eine Programmiersprache, die man
*auch* dazu verwenden kann, Seiteninhalte auf Papier, Film, etc. zu
bringen. PDF ist hingegen ein Metagraphikformat mit einem Objektmodell,
d.h. bringt erstmal schon wahnsinnig gute Voraussetzungen mit, wirklich
auf Objektbasis eingreifen zu können.
> Und genauso wenig, wie ich jemals direkt in Postscript "gesetzt" habe,
> macht es IMHO Sinn, direkt im PDF-Format zu arbeiten.
Ich bin, wie schon erwähnt, überhaupt kein Freund davon, in fertig
aufbereiteten "Druckdaten" noch last-minute Korrekturen anzubringen.
Allerdings sprachst Du die Notwendigkeit an, eben dieses zu tun. Und ich
wollte halt anmerken, daß sich PDF schon prinzipiell deutlich besser dafür
eignet als PostScript.
[CorelDraw-EPS ablehnen und PDF einfordern]
> [...] das sehe ich grundlegend anders. Wir sind ein Mediendienstleister,
> und unsere Aufgabe ist es, dem Kunden die größtmögliche Flexibilität bei
> der Verarbeitung _seiner_ Daten entgegenzubringen.
Bis dahin, ihm sämtliche Freiheiten zu geben, beliebigen Schrott
abzuliefern, der nur noch mit massivem Nachbearbeitungaufwand überhaupt aus
der Maschine zu kriegen ist? Ich sehe beim Dienstleister auch immer den Part
"Beratung", d.h. der Dienstleister darf seinen Kunden auch mal an der Hand
nehmen und ihm einen einfacheren, sichereren, profitableren Weg aufzeigen.
> Schließlich ist genau das unser Job ;-)
Das ist IMO eine Gratwanderung und es kommt auch noch drauf an, welches
Marktsegment man im Blick hat. Wie gesagt: Zu meiner aktiven Zeit ging das
teils so weit, daß gute Kunden *umsonst* beraten wurden, mit dem Ziel, Ihnen
klarzumachen, daß eine gefestigte Beziehung zwischen Kunde und Dienstleister
für beide Seiten einen Vorteil bringen kann. Vielleicht nicht mal unbedingt
einen finanziellen aber bspw. einen, der sich dahingehend niederschlägt, daß
sie für ein Magazin den Redaktionsschluß drei Tage weiter nach hinten legen
können. Daß dabei der Dienstleister, der ziemlich stark KnowHow-Transfer
macht, nicht zu kurz kommen darf, verstehen diejenigen Kunden von selbst,
die ein wenig rechnen können.
Auf der anderen Seite gibt es abseits des "guter Grosskunde" Szenariums
natürlich noch ganz andere Sachen. Als ich bei einem Bekannten in einem
Copyshop die komplette IT-Infrastruktur mal auf Vordermann gebracht habe,
war ich damit konfrontiert <schüttel>. Leute, die mit einer Diskette mit
CorelDraw Kram daherkamen, bunte Geburtstags-Einladungen wollten und nach
einer halben Stunde Beratungsgespräch wutentbrannt wieder den Laden
verliessen, weil das Fertigen von 50 Einladungen mehr als 10 Euro gekostet
hätte ("Da schreib ich's billiger mit der Hand!")
> Ich halte es für sehr bedenklich, dem Kunden zwingend eine Technik auf's
> Auge zu drücken, die für den technischen Laien nur bedingt beherschbar
> ist und deshalb ---> (*)
Wie gesagt: Es kommt drauf an, mit welcher Sorte Kunde man zu tun hat, bzw.
wie man seine Kundenzusammensetzung steuert. Ich persönlich mag lieber die,
mit denen man vernünftig über eine Verbesserung für beide Seiten reden
kann... Macht einfach mehr Spaß :-)
>>> Nun will der Kunde noch schnell einen Preis geändert haben ...
>>
>> Yo, dann darf er sein CorelDraw erneut bemühen und abermals ein PDF
>> schicken.
>
> Kann er gerne, muss er aber nicht ...
Ich bin da einfach aufgrund der Grösse der Aufträge, die ich früher aktiv zu
betreuen hatte, anders sensibilisiert, glaube ich. Wenn damals mal was
schiefgegangen ist und man musste bspw. 20.000 32-Seiter neu drucken, dann
war das noch vertretbar im Vergleich zu dem Horrorszenarium, das eingetreten
wäre, wenn die Nachdrucke nicht mehr rechtzeitig fertig geworden wären und
die Konfektionierung und Auslieferung kompletter Projekte geplatzt wäre.
>> Vielleicht bin ich da aus meiner "aktiven" Zeit noch zu sehr von zwei Sachen
>> geprägt: Kleinkundenausmistung einerseits und andererseits Schaffen von
>> Produktionssicherheit (in Form von Standards und Automatismen)
>
> (*) ---> die Produktionssicherheit eher gefährdet. Denn auch wenn ich
> mir PDF im Gegensatz zu PS nett am Bildschirm anschauen kann, können die
> internen Daten trotzdem ähnlich fehlerhaft sein wie bei einem PS-Job.
Nicht, wenn sie die "Waschmaschine" Distiller schon durchlaufen haben. Dann
können sie zwar in manchen Bereichen noch formal fehlerhaft sein und
natürlich weiterhin inhaltlich total falsch (das kann einem kein
Automatismus abfangen) aber es ist qualitativ trotzdem was ganz anderes.
> Und da helfen auch Preflight-Utilities nicht in jedem Fall weiter.
Die können die formalen Fehlerkriterien effizient prüfen. Das ist doch schon
mal was.
> Mir ist es da allemal lieber, der Kunde schickt eine offene Quark-Datei, aus
> der ich selbst ein sauberes EPS backen kann, als das er mir ein PDF
> unterjubelt, das mir heimlich ein paar zusätzliche Farbauszüge aus dem RIP
> quält o. ä.
Bzgl. der Farbauszüge: Lantana Crackerjack, Callas PDF Output Pro, (Adobe
InProduction) kennst Du?
Aber allgemein stimmt es natürlich: Wenn der Kunde keinen Peil von den
Erfordernissen, die danach in der Prozeßkette auftreten, hat dann kann man
die Übergabe von offenen Dateien gar nicht vermeiden (weia, haben wir uns
jetzt vom ursprünglichen Thema, EPS <--> PDF entfernt ;-)
Drum sollten Grafiker mindestens 2 Wochen Praktika in jeweils Buchbinderei,
Druckerei und Druckvorstufe absolvieren und dann noch ein Jahr gute Kurse
belegen, die ihnen zur Hälfte den Umgang mit der Software nahebringen und
zur anderen Hälfte sie mit den Basistechnologien vertraut machen, mit denen
man jeden Tag zu tun hat. Dann kann man ihnen zutrauen, produktionstaugliche
PDF zu erstellen.
>> Ich würde keine EPS annehmen, weil in einem EPS prinzipiell jeder Müll
>> drinstecken kann, der eben in PostScript möglich ist. Bei PDF sieht es
>> nicht gar so schlimm aus, v.a. kann man die Kunden dazu bringen, daß sie
>> bei sich bereits einen Preflight machen, d.h. viel Schrott gar nicht erst
>> zur Auslieferung kommt.
>
> Der gleiche Müll kann aber auch in einem PDF stecken,
Nein. Alleine schon wegen "Programmiersprache vs. Grafikformat".
> und Preflight-Checking auf Kundenseite ist auch nicht der Weisheit letzter
> Schluß.
Es kommt auf die Grösse des Kunden an (bzw. eher des Datenlieferanten, also
oft des Kunden des Kunden) bzw. das Verhältnis zwischen Euch.
> Ich kann ja kaum jedem, der bei einem unserer Verlags-Kunden eine Anzeige
> aufgibt, eine Acrobat-Vollversion inklusive PitStop schenken ...
Nein, das ist schon klar. In dem Fall lautet die Dienstleistung aber nicht
nur Datenausgabe sondern wahlweise ebenfalls "Datenveredelung" oder weniger
schön "Daten-Klärwerk". Sollte aber in jedem Fall separat verrechnet werden.
In der Situation kann man sich auch das mit der differenzierten Betrachtung,
wo die Verantwortung für was liegt, sparen. Wenn die Kunden mit "denn sie
wissen nicht, was sie tun" charakterisiert werden können, dann erübrigt sich
die Frage und man muß eher Wert auf verbindliche Freigabestrukturen legen.
>>> Was bisher geschah: EPS in Tailor öffnen, Preis ausbessern, sichern
>>> Was in Zukunft geschieht: EPS mit Distiller in PDF konvertieren, PDF in
>>> Acrobat öffnen, Preis ausbessern, PDF als EPS exportieren
>>
>> Wie gesagt: Mein Weg --> PDF annehmen/preflighten, PDF editieren, PDF
>> entweder auf Server klatschen (wenn Anzeige platziert werden soll -->
>> Grobbild einbauen)
>
> Das läßt sich sicher unter HELIOS alles wunderschön lösen. Aber nicht
> jeder hat/braucht HELIOS.
Ganz unabhängig von Helios (es gibt ja noch andere Anbieter stabiler
OPI-Server): Wenn ich technisches Consulting mache, dann steht die Frage,
was eingesetzt wird, immer ganz am Ende. Vorher kommt immer eine Analyse der
Abläufe und eine Sensiblisierung für das Überdenken derselben. Und oftmals
stellt sich dann trotzdem am Schluß heraus, daß man mit so einem uralten
Prinzip wie bspw. OPI und serverzentriertem Arbeiten Arbeitsabläufe durch
Entzerrung von aufeinanderfolgenden Abläufen wahnsinnig viel Zeit sparen
kann (für sich selbst als auch für den Kunden).
> Und ich werde mir jetzt nicht extra HELIOS zulegen, nur um Dinge, die ich
> unter OS 9 problemlos erledigen konnte, auch mit OS X-Arbeitsplätzen
> wieder machen zu können.
Klingt soweit logisch. Nur glaube ich, daß Du nicht mal ansatzweise weisst,
wie Dir ein OPI-Server bei Abläufen helfen könnte, zumal, wenn er wie bei
Helios mit *funktionierendem* ICC-basiertem Farbmanagement und Unterstützung
für PDF daherkommt. Warum ich das so frech annehme? Naja, wenn schon 95% der
Helios-Fachhändler nicht wissen, was die Software eigentlich kann, wie
sollten es dann erst die Endkunden wissen? ;-)
[Texte editieren in Acrobat]
> Interpretiere ich Deine Aussage richtig, dass es sinnvoller wäre,
> _keine_ Untergruppen zu bilden?
Exakt.
>>> Ebenso häufig kommt es vor, dass wir nur Teile des fertigen EPS (1 x
>>> Foto, 1 x Logobalken, 1 x Rahmen) benötigen. In Tailor kann ich mir
>>> die einzelnen Elemente gezielt als Einzel-Elemente raussichern
>
[Vorschlag, das mit PDF --> Illustrator zu machen]
> Das ist ja dann erst recht umständlich, noch ein Programm mehr
> dazwischen ;-)
Wieso? Der Weg PDF --> Illustrator ist doch recht geradlinig? Außerdem sind
Illustrator oder Freehand per Definition ziemlich geeignet dafür, Logos zu
überarbeiten, die man anschl. dann auch bequem editierbar speichern kann.
> Seit QXP 4 gibt es ja die Druckstile, damit geht das eh super einfach.
> Leider kann man da nicht auch gleich den Drucker mitspeichern.
Eben :-P
>> BTW: Kennst Du Made-to-Print und Autopilot von Callas?
>
> Vom Namen her, vielleicht auch schon mal eine Demo angeschaut. Erzähl'
> mal ...
Nee, guck einfach: <http://www.callas.de>
Es gibt Anwender davon (bspw. MetaDesign in Berlin), die damit so ziemlich
ohne jeglichen manuellen Aufwand ihre ganzen Standardjobs auf die diversen
Geräte jagen.
>> Ein guter Printserver wirkt oftmals Wunder ;-)
>
> ... insbesondere im Geldbeutel ;-)
Genau. Damit läßt sich bares Geld sparen. Sorry, aber wenn man ein Geschäft
betreibt, dann darf man sich keinen Kosten/Nutzen Rechnungen verschließen.
Blöd ist nur, daß den meisten (meine nicht Dich konkret) die Phantasie
fehlt, abschätzen zu können, wie sie ihre Arbeitsprozesse effizienter
gestalten können bzw. welche Möglichkeiten sie sich ins Haus holen mit einer
effizienten Drucklösung.
Wenn Druckserver nur Geld kosten würden ohne auf der anderen Seite
vernünftigtes Einsparpotential zu bieten, wären wohl alle Anwender derselben
als Idioten zu klassifizieren, oder? ;-)
Aber es hängt sehr stark von den jeweiligen Jobs ab, um die es geht -- sowas
müsste man sich im Detail anschauen...
> gerade so, als ob der Mac noch nie für DTP eingesetzt worden wäre ...
Das war früher. Heute sind Macs zum Schneiden von Urlaubsvideos da.
["hässliches UNIX-Skripting" hinter den Kulissen, bspw. CUPS-Backend]
> Wer A sagt, muss auch B sagen: Dann verrate doch mal, wie's geht ;-)
Wie es geht, habe ich doch schon recht konkret gepostet, darüberhinaus, wo
die relevanten Informationen zu finden sind.
Wenn ich sowas für Dich umsetzen soll, dann fühl Dich frei, per eMail ein
Angebot anzufordern ;-)
Wobei ich als Gegenvorschlag wahrscheinlich eher einen Tag Beratung
einbringen würde, da das aus meiner Sicht für Dich effizienter ist, als
die "Hopplahopp"-Implementierung von smarten Lösungen an den falschen
Stellen ;-))
Gruss,
Thomas
Thomas Kaiser
<news:BA5451EF.3A032%tsch...@gmx.net>:
> Siehst du das nicht etwas Einseitig aus der Perspektive einer Druckerei?
War mir klar, daß das kommt, jetzt wo die Diskussion so langsam von "EPS vs.
PDF als Austauschformat" zu "lieber offene vs. geschlossene Daten übergeben"
mutiert ist ;-)
> Es gibt ja noch andere Betriebe die z.B. davon Leben, Anzeigen usw.
> vernünftig aufzubereiten, nötigenfalls auch Filme redigitalisieren ...
Yo, genau in solchen Betrieben habe ich seit meinem Einstieg ins graphische
Gewerbe gearbeitet. Wobei man sich nie auf eine Rolle festlegen konnte; mal
war man reiner Ausgabedienstleister (PDF rein, Film/Druckplatte/fertiges
Objekt raus), mal Datenveredler (Berge von Daten-CDs rein, PDFs oder
PostScript-Dateien raus), mal nur Bildlieferant per Digitalkamera ("Kreisch!
Die Bilder sehen zum K***en aus!" -- "Aber, aber, sie haben doch zugestimmt,
Bilder mit getaggten Profilen zu akzeptieren" <seufz>), meistens aber
Mischform in bunten Kombinationen.
> Macht glaube ich nicht immer Sinn, den Kunden auf PDF zu zwingen
Nein, völlig klar. Ich hab' ja auch in dem Thread schon dementsprechend
differenziert.
Man kann da nicht verallgemeinern; es kommt eben drauf an, welche Beziehung
man zwischen Kunde und Dienstleister hat und welchen Stellenwert was hat.
Die Geschichte mit dem "Beraten des Kunden" geht bspw. regelmässig nach
hinten los, wenn man es mit Agenturen zu tun hat, die primär von absolut
unterbezahlten Nachwuchsgrafikern leben. Hat man denen nämlich erstmal die
Basics beigebracht, schon sind sie weg, weil sie woanders das dreifache
kriegen und man kann anfangen, der/die nächste(n) der Fernausbildung
zuzuführen ;-)
Aber bzgl. EPS vs. PDF bleibe ich einfach renitent auf meinem Standpunkt :-)
> Da kannst du vielleicht noch sagen, selbst verbockt, hilft aber nicht viel
> -- der Anzeigenkunde ist verloren.
Apropos verbockte Anzeigen: Zum Glück (im nachhinein) kam für mich das
bisher heikelste Projekt in der Hinsicht nie zustande. Wäre darum gegangen,
die Druckdaten für die auflagenstärkste Monatszeitschrift (klingt so ähnlich
wie "AC/DC Motörhead") für den Tiefdruck aufzubereiten. Allerdings hat der
Nettoanzeigenumsatz dieses Objekts den Gesamtumsatz der Firmengruppe, für
die ich damals arbeitete, deutlich überstiegen. Da hätte man vermutlich nach
der ersten Anzeigenreklamation wegen 2% Farbabweichung oder einem 1 mm
falsch platzierten Logo einfach zusperren können. Bezahlbare Versicherungen
für sowas gibt's nämlich nicht :-(
Gruss,
Thomas
Dirk Taggesell
Öhemm, ein Kunde hatte eine Acrobat-Vollversion, die in Classic startete.
Ich habe ihm das aktuelle Update von der Adobe-Site installiert und ab
sofort lief das Teil ohne Classic. Die genaue URL weiß ich nicht mehr.
Achim Denzl
> Allerdings sprachst Du die Notwendigkeit an, eben dieses zu tun. Und ich
> wollte halt anmerken, daß sich PDF schon prinzipiell deutlich besser dafür
> eignet als PostScript.
ACK.
> [CorelDraw-EPS ablehnen und PDF einfordern]
> > [...] das sehe ich grundlegend anders. Wir sind ein Mediendienstleister,
> > und unsere Aufgabe ist es, dem Kunden die größtmögliche Flexibilität bei
> > der Verarbeitung _seiner_ Daten entgegenzubringen.
>
> Bis dahin, ihm sämtliche Freiheiten zu geben, beliebigen Schrott
> abzuliefern, der nur noch mit massivem Nachbearbeitungaufwand überhaupt aus
> der Maschine zu kriegen ist? Ich sehe beim Dienstleister auch immer den Part
> "Beratung", d.h. der Dienstleister darf seinen Kunden auch mal an der Hand
> nehmen und ihm einen einfacheren, sichereren, profitableren Weg aufzeigen.
Das ist natürlich richtig. Andererseits unterscheiden wir uns auch
gerade dadurch von anderen Setzereien, dass wir auch die "unmöglichen"
Jobs machen. Gestern habe ich mich z.B. damit abgequält, eine
PowerPoint-Datei 2-farbig auszubelichten; ein Job, bei dem die meisten
anderen Satzstudios gleich stumm auf die Tür deuten. Aber solche
Spielereien muss der Kunde natürlich auch bezahlen.
[...]
> Auf der anderen Seite gibt es abseits des "guter Grosskunde" Szenariums
> natürlich noch ganz andere Sachen. Als ich bei einem Bekannten in einem
> Copyshop die komplette IT-Infrastruktur mal auf Vordermann gebracht habe,
> war ich damit konfrontiert <schüttel>. Leute, die mit einer Diskette mit
> CorelDraw Kram daherkamen, bunte Geburtstags-Einladungen wollten und nach
> einer halben Stunde Beratungsgespräch wutentbrannt wieder den Laden
> verliessen, weil das Fertigen von 50 Einladungen mehr als 10 Euro gekostet
> hätte ("Da schreib ich's billiger mit der Hand!")
Für diese Fälle sollte man immer eine Kiste Wachsmalkreiden in der
Schublade haben ;-)
> > Ich halte es für sehr bedenklich, dem Kunden zwingend eine Technik auf's
> > Auge zu drücken, die für den technischen Laien nur bedingt beherschbar
> > ist und deshalb ---> (*)
>
> Wie gesagt: Es kommt drauf an, mit welcher Sorte Kunde man zu tun hat, bzw.
> wie man seine Kundenzusammensetzung steuert. Ich persönlich mag lieber die,
> mit denen man vernünftig über eine Verbesserung für beide Seiten reden
> kann... Macht einfach mehr Spaß :-)
Völlig richtig, mit _unseren_ Kunden handhaben wir das genauso. Aber wir
wenig Einfluss auf die Kunden unserer Verlagskunden ...
> >>> Nun will der Kunde noch schnell einen Preis geändert haben ...
> >>
> >> Yo, dann darf er sein CorelDraw erneut bemühen und abermals ein PDF
> >> schicken.
> >
> > Kann er gerne, muss er aber nicht ...
>
> Ich bin da einfach aufgrund der Grösse der Aufträge, die ich früher aktiv zu
> betreuen hatte, anders sensibilisiert, glaube ich. Wenn damals mal was
> schiefgegangen ist und man musste bspw. 20.000 32-Seiter neu drucken, dann
> war das noch vertretbar im Vergleich zu dem Horrorszenarium, das eingetreten
> wäre, wenn die Nachdrucke nicht mehr rechtzeitig fertig geworden wären und
> die Konfektionierung und Auslieferung kompletter Projekte geplatzt wäre.
Klar, irgendwann ist auch die "last minute" vorbei ;-)
> >> Vielleicht bin ich da aus meiner "aktiven" Zeit noch zu sehr von zwei
> >> Sachen geprägt: Kleinkundenausmistung einerseits und andererseits
> >> Schaffen von Produktionssicherheit (in Form von Standards und
> >> Automatismen)
> >
> > (*) ---> die Produktionssicherheit eher gefährdet. Denn auch wenn ich
> > mir PDF im Gegensatz zu PS nett am Bildschirm anschauen kann, können die
> > internen Daten trotzdem ähnlich fehlerhaft sein wie bei einem PS-Job.
>
> Nicht, wenn sie die "Waschmaschine" Distiller schon durchlaufen haben. Dann
> können sie zwar in manchen Bereichen noch formal fehlerhaft sein und
> natürlich weiterhin inhaltlich total falsch (das kann einem kein
> Automatismus abfangen) aber es ist qualitativ trotzdem was ganz anderes.
Das ist so aber nicht ganz richtig, denn auch PDFs können die gleichen
Fallstricke beinhalten wie PS-Dateien, zum Teil sogar noch tückischer.
Ein Beispiel, das bei uns schon ein paar Mal aufgetreten ist und wo
momentan noch keiner so richtig eine Lösung hat:
Wir bekommen eine Anzeige als PDF, soweit OK.
Anzeige wird mit Acrobat in EPS konvertiert.
EPS in QXP auf Seite platziert.
QXP-Seite in PS-Datei gesichert.
PS-Datei destilliert.
PDF-Datei in Avrobat visuell überprüft, alles ok.
Aber dann: Beim Belichten wird nur ein kleiner Teil der Seite belichtet,
in exakt der Größe und Position der ursprünglichen Anzeige! Irgendeine
der (Trim-, Bleed-, Bounding- und wie sie alle heissen mögen)-Boxen hat
also tatsächlich den weiten Weg PDF-EPS-PS-PDF überlebt und beschneidet
die Seite ;-(
> > Und da helfen auch Preflight-Utilities nicht in jedem Fall weiter.
>
> Die können die formalen Fehlerkriterien effizient prüfen. Das ist doch schon
> mal was.
Das ist schon mal ein Ansatz. Da ich die PDFs aber zum Platzieren in
Quark sowieso in ein EPS verwandeln muss, erschien mir Tailor dafür
bisher immer zuverlässiger, denn wenn der ein EPS als OK einstufte, dann
war es das auch. Und wenn nicht, konnte man das auch sofort ändern.
Insofern ist ein PDF-Preflight-Werkzeug eh nur die halbe Miete, denn
letztendlich brauche ich in jedem Fall noch ein zweites Tool, um die
gefundenen Fehler dann auch zu beseitigen. Deshalb fällt es mir sehr
schwer, auf Tailor zu verzichten ...
> > Mir ist es da allemal lieber, der Kunde schickt eine offene Quark-Datei, aus
> > der ich selbst ein sauberes EPS backen kann, als das er mir ein PDF
> > unterjubelt, das mir heimlich ein paar zusätzliche Farbauszüge aus dem RIP
> > quält o. ä.
>
> Bzgl. der Farbauszüge: Lantana Crackerjack, Callas PDF Output Pro, (Adobe
> InProduction) kennst Du?
Ja, ansatzweise. Die würden mir aber nur helfen, wenn die Ausbelichtung
bei uns im Haus stattfinden würde. Bei unseren größeren Produktionen ist
das aber mittlerweile nicht mehr der Fall ...
> Aber allgemein stimmt es natürlich: Wenn der Kunde keinen Peil von den
> Erfordernissen, die danach in der Prozeßkette auftreten, hat dann kann man
> die Übergabe von offenen Dateien gar nicht vermeiden (weia, haben wir uns
> jetzt vom ursprünglichen Thema, EPS <--> PDF entfernt ;-)
>
> Drum sollten Grafiker mindestens 2 Wochen Praktika in jeweils Buchbinderei,
> Druckerei und Druckvorstufe absolvieren und dann noch ein Jahr gute Kurse
> belegen, die ihnen zur Hälfte den Umgang mit der Software nahebringen und
> zur anderen Hälfte sie mit den Basistechnologien vertraut machen, mit denen
> man jeden Tag zu tun hat. Dann kann man ihnen zutrauen, produktionstaugliche
> PDF zu erstellen.
ACK. Aber viele scheuen noch ein wenig davor zurück, sich mit dem
Grafikformat ;-) PDF auseinanderzusetzen. Zumindest habe ich häufig
diesen Eindruck.
> >> Ich würde keine EPS annehmen, weil in einem EPS prinzipiell jeder Müll
> >> drinstecken kann, der eben in PostScript möglich ist. Bei PDF sieht es
> >> nicht gar so schlimm aus, v.a. kann man die Kunden dazu bringen, daß sie
> >> bei sich bereits einen Preflight machen, d.h. viel Schrott gar nicht erst
> >> zur Auslieferung kommt.
> >
> > Der gleiche Müll kann aber auch in einem PDF stecken,
>
> Nein. Alleine schon wegen "Programmiersprache vs. Grafikformat".
Das ist aber auch keine Garantie, siehe oben.
> > Das läßt sich sicher unter HELIOS alles wunderschön lösen. Aber nicht
> > jeder hat/braucht HELIOS.
>
> Ganz unabhängig von Helios (es gibt ja noch andere Anbieter stabiler
> OPI-Server): Wenn ich technisches Consulting mache, dann steht die Frage,
> was eingesetzt wird, immer ganz am Ende. Vorher kommt immer eine Analyse der
> Abläufe und eine Sensiblisierung für das Überdenken derselben. Und oftmals
> stellt sich dann trotzdem am Schluß heraus, daß man mit so einem uralten
> Prinzip wie bspw. OPI und serverzentriertem Arbeiten Arbeitsabläufe durch
> Entzerrung von aufeinanderfolgenden Abläufen wahnsinnig viel Zeit sparen
> kann (für sich selbst als auch für den Kunden).
Völlig richtig. Und vermutlich war ich einer der ersten *g*, der die
HELIOS Public Beta installiert und getestet hat. Nur richtig brauchen tu
ich das Teil nicht, zumal ja auch HELIOS zur PDF-Erzeugung einfach
PS-Daten übers Netzwerk (!) zu einem Distiller-Rechner schickt und von
dort wieder abholt. Wir machen das genauso, nur ohne HELIOS dazwischen.
Das Konzept und die Leistungsfähigkeit von HELIOS sind genial, aber
unsere Abläufe würden davon nicht wesentlich profotieren. Und für
"einfach mal zum Spaß" ist das Teil wiederum zu teuer.
> > Und ich werde mir jetzt nicht extra HELIOS zulegen, nur um Dinge, die ich
> > unter OS 9 problemlos erledigen konnte, auch mit OS X-Arbeitsplätzen
> > wieder machen zu können.
>
> Klingt soweit logisch. Nur glaube ich, daß Du nicht mal ansatzweise weisst,
> wie Dir ein OPI-Server bei Abläufen helfen könnte, zumal, wenn er wie bei
> Helios mit *funktionierendem* ICC-basiertem Farbmanagement und Unterstützung
> für PDF daherkommt. Warum ich das so frech annehme? Naja, wenn schon 95% der
> Helios-Fachhändler nicht wissen, was die Software eigentlich kann, wie
> sollten es dann erst die Endkunden wissen? ;-)
Für mich ist HELIOS durchaus eine interessante Alternative für die
Zukunft. Momentan ist unser ASIP-Server noch gut im Rennen und bietet
die Leistung, die wir brauchen, plus entsprechende Reserven. Aber
irgendwann kommt der Zeitpunkt, und dann wird man zwischen OS X Server
und HELIOS auswählen müssen. Mein Favorit stünde eigentlich schon fest.
> Wieso? Der Weg PDF --> Illustrator ist doch recht geradlinig? Außerdem sind
> Illustrator oder Freehand per Definition ziemlich geeignet dafür, Logos zu
> überarbeiten, die man anschl. dann auch bequem editierbar speichern kann.
Tja, leider sind wir FreeHandler ;-(
> >> BTW: Kennst Du Made-to-Print und Autopilot von Callas?
> >
> > Vom Namen her, vielleicht auch schon mal eine Demo angeschaut. Erzähl'
> > mal ...
>
> Nee, guck einfach: <http://www.callas.de>
>
> Es gibt Anwender davon (bspw. MetaDesign in Berlin), die damit so ziemlich
> ohne jeglichen manuellen Aufwand ihre ganzen Standardjobs auf die diversen
> Geräte jagen.
Das werde ich mir bei Gelegenheit mal anschauen ...
> >> Ein guter Printserver wirkt oftmals Wunder ;-)
> >
> > ... insbesondere im Geldbeutel ;-)
>
> Genau. Damit läßt sich bares Geld sparen. Sorry, aber wenn man ein Geschäft
> betreibt, dann darf man sich keinen Kosten/Nutzen Rechnungen verschließen.
>
> Blöd ist nur, daß den meisten (meine nicht Dich konkret) die Phantasie
> fehlt, abschätzen zu können, wie sie ihre Arbeitsprozesse effizienter
> gestalten können bzw. welche Möglichkeiten sie sich ins Haus holen mit einer
> effizienten Drucklösung.
>
> Wenn Druckserver nur Geld kosten würden ohne auf der anderen Seite
> vernünftigtes Einsparpotential zu bieten, wären wohl alle Anwender derselben
> als Idioten zu klassifizieren, oder? ;-)
Natürlich nicht. Aber ein Printserver bringt auch nur dann wirklich was,
wenn man ihn entsprechend auslasten kann ...
> Aber es hängt sehr stark von den jeweiligen Jobs ab, um die es geht -- sowas
> müsste man sich im Detail anschauen...
Eben.
> > gerade so, als ob der Mac noch nie für DTP eingesetzt worden wäre ...
>
> Das war früher. Heute sind Macs zum Schneiden von Urlaubsvideos da.
Yepp. Und da geht nix über iMovie und iDVD unter OS X. Jawoll!
> ["hässliches UNIX-Skripting" hinter den Kulissen, bspw. CUPS-Backend]
> > Wer A sagt, muss auch B sagen: Dann verrate doch mal, wie's geht ;-)
>
> Wie es geht, habe ich doch schon recht konkret gepostet, darüberhinaus, wo
> die relevanten Informationen zu finden sind.
>
> Wenn ich sowas für Dich umsetzen soll, dann fühl Dich frei, per eMail ein
> Angebot anzufordern ;-)
>
> Wobei ich als Gegenvorschlag wahrscheinlich eher einen Tag Beratung
> einbringen würde, da das aus meiner Sicht für Dich effizienter ist, als
> die "Hopplahopp"-Implementierung von smarten Lösungen an den falschen
> Stellen ;-))
Naja, noch drängt die Zeit nicht und ich habe noch viel Gelegenheit zum
Grübeln und Basteln ;-)
Thomas Kaiser
<news:1fp7ouf.1gtopi58xn8nmN%use...@dtpd.com>:
> Gestern habe ich mich z.B. damit abgequält, eine PowerPoint-Datei 2-farbig
> auszubelichten; ein Job, bei dem die meisten anderen Satzstudios gleich
> stumm auf die Tür deuten.
*ggg*
> Aber solche Spielereien muss der Kunde natürlich auch bezahlen.
Logo. Ich glaube, wir haben aneinander vorbei geschrieben, denn Du bist
wahrscheinlich ebenso der Meinung, daß man diesem Kunden, wenn er das zehnte
mal mit PP-Schraddel vor der Tür steht, mal den Tipp geben darf, sich das
Leben einfacher und die Mehraufwandskosten niedriger zu machen?
> auch PDFs können die gleichen Fallstricke beinhalten wie PS-Dateien, zum
> Teil sogar noch tückischer.
Nein :-)
> Ein Beispiel, das bei uns schon ein paar Mal aufgetreten ist und wo
> momentan noch keiner so richtig eine Lösung hat:
Vorab: Man kann beim Distillen die Boxen per PDFMarks setzen, wie man will
(am Besten halt auf das richtige Format) und das kostenlose PlugIn "Prinergy
Geometry Editor" kann die Boxen visuell darstellen als auch ändern. Zuletzt
kann man mit bspw. PitStop (Server) den Kram auch via Aktionsliste
automatisch richtig setzen lassen.
> Wir bekommen eine Anzeige als PDF, soweit OK.
> Anzeige wird mit Acrobat in EPS konvertiert.
> EPS in QXP auf Seite platziert.
> QXP-Seite in PS-Datei gesichert.
> PS-Datei destilliert.
> PDF-Datei in Avrobat visuell überprüft, alles ok.
*Nur* visuell überprüfen bringt gar nichts in mehrerlei Hinsicht. Muß immer
eine Kombination aus Überprüfung auf formaler Mängel (durch Werkzeug, das in
die Struktur von PDFs gucken kann) und visueller Überprüfung zwengs
inhaltlicher Fehler sein.
> Aber dann: Beim Belichten wird nur ein kleiner Teil der Seite belichtet,
> in exakt der Größe und Position der ursprünglichen Anzeige! Irgendeine
> der (Trim-, Bleed-, Bounding- und wie sie alle heissen mögen)-Boxen
Denzl, klare Terminologie bitte! ;-)
<http://www.pdfzone.de/aktuell/show.php3?nid=136&mission=aktuell>
> hat also tatsächlich den weiten Weg PDF-EPS-PS-PDF überlebt und beschneidet
> die Seite ;-(
Naja, was für den Anzeigeninhalt recht und billig ist, muß es doch auch für
Metadaten wie die entsprechende Media- bzw Cropbox ebenso sein ;-)
Man muß halt nur wissen, was die Boxen konkret bedeuten und wie man ihrer
Herr wird :-)
>> Bzgl. der Farbauszüge: Lantana Crackerjack, Callas PDF Output Pro, (Adobe
>> InProduction) kennst Du?
>
> Ja, ansatzweise. Die würden mir aber nur helfen, wenn die Ausbelichtung
> bei uns im Haus stattfinden würde.
Du kannst damit auch PostScript-Dateien erstellen. Aber wahrscheinlich ist
PDF das Format der Wahl, um die Druckdaten weiter zu schleifen?
> Bei unseren größeren Produktionen ist das aber mittlerweile nicht mehr
> der Fall ...
Dann liegt der schwarze Peter eben beim endgültigen Verarbeiter. Wenn die
keinen Peil haben, wie man eine InRIP-Separation parametrisiert, dann müssen
sie halt Schulungen besuchen. Man kann nicht mit dem Wissensstand Anfang der
90er Jahre des letzten Jahrhunderts heute noch produktiv arbeiten.
> Völlig richtig. Und vermutlich war ich einer der ersten *g*, der die
> HELIOS Public Beta installiert und getestet hat. Nur richtig brauchen tu
> ich das Teil nicht,
Naja, Dir hat halt noch niemand mit leicht glasigen Augen vorgeschwärmt und
gezeigt, was man alles für abgefahrene Sachen machen kann. Viele Perlen
stecken unter der Haube und die nimmt man bei einem oberflächlichen Test gar
nicht wahr. Aber egal...
> zumal ja auch HELIOS zur PDF-Erzeugung einfach PS-Daten übers Netzwerk (!)
> zu einem Distiller-Rechner schickt und von dort wieder abholt.
Yo. Einfach genial. Kein temporäres Dateihandling auf dem Distiller-Rechner
(damit v.a. der Mac-Distiller *dramatisch* und zum Teil um den Faktor 10 zu
beschleunigen), bidirektionale Kommunikation mit dem Distiller (also
Einbindung in die Notification-Szenarien des Servers -- schon gemerkt, daß
der Server bei Fehlern die Jobs automatisch nachbearbeiten kann, Dir eine
eMail schickt, eine AFP-Message auf den Schirm werfen kann und natürlich
auch noch Buch führt? ;-)
> Wir machen das genauso, nur ohne HELIOS dazwischen.
Ihr macht das erstmal deutlich langsamer und ohne Integration und
transparente Benachrichtigungsszenarien.
> Das Konzept und die Leistungsfähigkeit von HELIOS sind genial, aber
> unsere Abläufe würden davon nicht wesentlich profotieren.
Ich würde mich ja fast auf eine Wette einlassen. Bist Du ein fairer
Verlierer?
> Und für "einfach mal zum Spaß" ist das Teil wiederum zu teuer.
Sehe ich ähnlich. Es muß zu den Anforderungen passen und sich sinnvoll
integrieren um letzten Endes die Produktivität zu steigern. Nur wissen eben
viele nichts über die Features und welche Arbeitsweisen alle möglich wären.
Naja, hier wohl langsam extrem OT.
> ein Printserver bringt auch nur dann wirklich was, wenn man ihn entsprechend
> auslasten kann ...
Das ist die Durchsatzkomponente. Und dann gibt es eben noch die
Komfort-Komponente, einfach dieses "Ich baller es mal los und kümmer mich
erst wieder darum, wenn ich vom Server eine Mail kriege" :-)
> Naja, noch drängt die Zeit nicht und ich habe noch viel Gelegenheit zum
> Grübeln und Basteln ;-)
Wo kann man eigentlich "legal" über solche Themen plauschen? Denn ist ja
nicht wirklich Mac-spezifisch und ich habe immer ein schlechtes Gewissen,
wenn wir uns hier mit dem DTP-Kram breitmachen...
Gruss,
Thomas
Willi Hackmann
> Öhemm, ein Kunde hatte eine Acrobat-Vollversion, die in Classic startete.
> Ich habe ihm das aktuelle Update von der Adobe-Site installiert und ab
> sofort lief das Teil ohne Classic. Die genaue URL weiß ich nicht mehr.
Acrobat ja, aber nicht der Distiller.
Ciao
Willi
Konni Scheller
> Wo kann man eigentlich "legal" über solche Themen plauschen? Denn ist ja
> nicht wirklich Mac-spezifisch und ich habe immer ein schlechtes Gewissen,
> wenn wir uns hier mit dem DTP-Kram breitmachen...
nene, machmal weiter, das ist hochinteressant...
meint
Konni
Uwe Senkler
> Wo kann man eigentlich "legal" über solche Themen plauschen?
de.comp.text.dtp wäre wohl eine geeignete Gruppe, aber
wg. mir könnt ihr hier gern weitermachen.
Clemens Beier
> Wo kann man eigentlich "legal" über solche Themen plauschen? Denn ist ja
> nicht wirklich Mac-spezifisch und ich habe immer ein schlechtes Gewissen,
> wenn wir uns hier mit dem DTP-Kram breitmachen...
Bitte bleiben oder nur nach *soc* verziehen!
Ein stiller Leser,
ClemiSan
Stefan Schoenberger
> Wo kann man eigentlich "legal" über solche Themen plauschen? Denn ist ja
> nicht wirklich Mac-spezifisch und ich habe immer ein schlechtes Gewissen,
> wenn wir uns hier mit dem DTP-Kram breitmachen...
na, diese Gruppe heißt doch schon *.misc :-) Also bitte hier breitmachen, ich
lese auch mal gerne über meinen Tellerrand 'raus.
Stefan
Achim Denzl
> > Gestern habe ich mich z.B. damit abgequält, eine PowerPoint-Datei 2-farbig
> > auszubelichten; ein Job, bei dem die meisten anderen Satzstudios gleich
> > stumm auf die Tür deuten.
>
> *ggg*
Es ist aber leider auch wirklich ziemlich abstrus, was die MS-Programme
an Output liefern. Bei Powerpoint werden z.B. Schriften sehr merkwürdig
in den PS-Code übernommen; ein Außenlinie eines "o" besteht nicht nur
aus einem Pfad, wie man das erwarten würde, sondern mehrere Pfade, die
ungefähr (!) der Kontur des Buchstaben folgen, liegen leicht versetzt
übereinander. Und diese Pfade liegen noch nicht mal ordentlich parallel.
Fast so, als ob man die Bildschrimdarstellung tracen würde; ist
vermutlich auch der Fall ;-(
Aber so richtig habe ich mir erst die Hand auf's Hirn geklatscht, als
ich vor einiger Zeit einige Seiten aus dem MS Publisher belichten
sollte, ein Programm, das MS durchaus ernsthaft im semiprofessionellen
Bereich platziert sehen möchte. Erst mal etwas Verwunderung, dass MSP
alle Schriften als Zeichenwege ausgibt. Wenn man sich das dann aber noch
mit einem Flattening-Paramter von 8-12 vorstellt, kommt man dem Ergebnis
ziemlich nahe. Ein ehemals rundes "o" sieht dann unter dem Fadenzähler
ungefähr so aus:
/ \
\ /
Lauter gerade (!) Linien. Mehr sog I ned ;-)
> > Aber solche Spielereien muss der Kunde natürlich auch bezahlen.
>
> Logo. Ich glaube, wir haben aneinander vorbei geschrieben, denn Du bist
> wahrscheinlich ebenso der Meinung, daß man diesem Kunden, wenn er das zehnte
> mal mit PP-Schraddel vor der Tür steht, mal den Tipp geben darf, sich das
> Leben einfacher und die Mehraufwandskosten niedriger zu machen?
Klar, genau Deiner Meinung. Wir bieten dem Kunden dann meistens an, das
Ganze bei uns nachzusetzen. Ist meistens sogar billiger, und hübscher
sowieso ;-)
> > auch PDFs können die gleichen Fallstricke beinhalten wie PS-Dateien, zum
> > Teil sogar noch tückischer.
>
> Nein :-)
>
> > Ein Beispiel, das bei uns schon ein paar Mal aufgetreten ist und wo
> > momentan noch keiner so richtig eine Lösung hat:
>
> Vorab: Man kann beim Distillen die Boxen per PDFMarks setzen, wie man will
> (am Besten halt auf das richtige Format) und das kostenlose PlugIn "Prinergy
> Geometry Editor" kann die Boxen visuell darstellen als auch ändern. Zuletzt
> kann man mit bspw. PitStop (Server) den Kram auch via Aktionsliste
> automatisch richtig setzen lassen.
Klar kann man den Fehler beseitigen. Aber besser wäre es doch, wenn der
Fehler gar nicht erst auftauchen würde. Momentan ist auch noch gar nicht
klar, wo der Fehler eigentlich entsteht. Die Seiten werden in der
Druckerei mit ASURA und SOLVERO weiterverarbeitet, und erst da zeigt
sich der besagte Fehler. Ich hatte damals ein paar Mails mit dem (sehr
kompetenten) Support von OneVision ausgetauscht, aber ad hoc ließ sich
auch nicht herausfinden, ob nicht möglicherweise da der Fehler steckt.
> > Wir bekommen eine Anzeige als PDF, soweit OK.
> > Anzeige wird mit Acrobat in EPS konvertiert.
> > EPS in QXP auf Seite platziert.
> > QXP-Seite in PS-Datei gesichert.
> > PS-Datei destilliert.
> > PDF-Datei in Avrobat visuell überprüft, alles ok.
>
> *Nur* visuell überprüfen bringt gar nichts in mehrerlei Hinsicht. Muß immer
> eine Kombination aus Überprüfung auf formaler Mängel (durch Werkzeug, das in
> die Struktur von PDFs gucken kann) und visueller Überprüfung zwengs
> inhaltlicher Fehler sein.
Das waäre vermutlich eine optimale Lösung. Allerdings ist mir bisher
kein vernünftiges Allround-Tool untergekommen, und jeden Arbeitsplatz
mit einer Fülle von Werkzeugen (PitStop, Quite-a-box-of-tricks, etc.)
auszustatten, ist mir auch wieder zu heftig, auch was die
Mitarbeiterschulung anbelangt. Aber sag' doch mal: Was würdest Du denn
von Pitstop-Server halten? Könnte das helfen?
> > Aber dann: Beim Belichten wird nur ein kleiner Teil der Seite belichtet,
> > in exakt der Größe und Position der ursprünglichen Anzeige! Irgendeine
> > der (Trim-, Bleed-, Bounding- und wie sie alle heissen mögen)-Boxen
>
> Denzl, klare Terminologie bitte! ;-)
>
> <http://www.pdfzone.de/aktuell/show.php3?nid=136&mission=aktuell>
Ich schrub's ja schon: Welche Box genau Probleme macht, ließ sich bis
jetzt (mangels passender Tools) noch nicht rausfinden. Aber trotzdem
Danke für den Link, der kommt in jedem Fall in die Bookmarks ;-)
> > hat also tatsächlich den weiten Weg PDF-EPS-PS-PDF überlebt und beschneidet
> > die Seite ;-(
>
> Naja, was für den Anzeigeninhalt recht und billig ist, muß es doch auch für
> Metadaten wie die entsprechende Media- bzw Cropbox ebenso sein ;-)
>
> Man muß halt nur wissen, was die Boxen konkret bedeuten und wie man ihrer
> Herr wird :-)
Schon klar. Ich hatte mich nur darüber gewundert, dass es eine EPS-Datei
schafft, auch "fremden" PS-Code in der Ganzseiten-Datei zu verändern.
Aber da sind wir wieder beim Thema "PS ist eine Programmiersprache" ...
> >> Bzgl. der Farbauszüge: Lantana Crackerjack, Callas PDF Output Pro, (Adobe
> >> InProduction) kennst Du?
> >
> > Ja, ansatzweise. Die würden mir aber nur helfen, wenn die Ausbelichtung
> > bei uns im Haus stattfinden würde.
>
> Du kannst damit auch PostScript-Dateien erstellen. Aber wahrscheinlich ist
> PDF das Format der Wahl, um die Druckdaten weiter zu schleifen?
Genau. Wir haben früher selbst belichtet bzw. separierte PS-Files
verschickt, was auch bei 4-Kanal-Übertragung satte Übertragungszeiten
liefert. Deshalb, und auch auf Drängen der Druckereien (die endlich die
Seitenkleber entlassen wollten, Bäh!) haben wir dann zu Composite-PDF
gewechselt.
> > Völlig richtig. Und vermutlich war ich einer der ersten *g*, der die
> > HELIOS Public Beta installiert und getestet hat. Nur richtig brauchen tu
> > ich das Teil nicht,
>
> Naja, Dir hat halt noch niemand mit leicht glasigen Augen vorgeschwärmt und
> gezeigt, was man alles für abgefahrene Sachen machen kann. Viele Perlen
> stecken unter der Haube und die nimmt man bei einem oberflächlichen Test gar
> nicht wahr. Aber egal...
Ich hab' mir mal einen Teil des Manuals reingezogen, in dem die ganzen
Parameter beschrieben sind, insbesondere auch die, die nicht über ein
GUI erreichbar sind. Das ist alles ziemlich komplex, aber die
Möglichkeiten sind mit Sicherheit fantastisch, wenn man etwas in die
Tiefe geht.
> > zumal ja auch HELIOS zur PDF-Erzeugung einfach PS-Daten übers Netzwerk (!)
> > zu einem Distiller-Rechner schickt und von dort wieder abholt.
>
> Yo. Einfach genial. Kein temporäres Dateihandling auf dem Distiller-Rechner
> (damit v.a. der Mac-Distiller *dramatisch* und zum Teil um den Faktor 10 zu
> beschleunigen), bidirektionale Kommunikation mit dem Distiller (also
> Einbindung in die Notification-Szenarien des Servers -- schon gemerkt, daß
> der Server bei Fehlern die Jobs automatisch nachbearbeiten kann, Dir eine
> eMail schickt, eine AFP-Message auf den Schirm werfen kann und natürlich
> auch noch Buch führt? ;-)
Klar ist das alles sehr komfortabel und performant gelöst. Allerdings
laufen bei uns ca. 99 von 100 ps-Files sauber durch, und nur eines
spuckt ein log aus. Das kriegt man auch noch per Hand in den Griff ;-)
> > Das Konzept und die Leistungsfähigkeit von HELIOS sind genial, aber
> > unsere Abläufe würden davon nicht wesentlich profotieren.
>
> Ich würde mich ja fast auf eine Wette einlassen. Bist Du ein fairer
> Verlierer?
Ja, bin ich. Aber es kommt auf den Blickwinkel an: Bezüglich Komfort,
Performance und Produktionssicherheit gebe ich Dir Recht. Die
Kosten-/Nutzen-Analyse spricht aber bei unserem momentanen Durchsatz
(den Du natürlich von außen nicht beurteilen kannst) dagegen. Insofern
steht es 3:1 für Dich, und damit gewinnst Du so viele Waschmaschinen,
wie Du tragen kannst ;-)
> Wo kann man eigentlich "legal" über solche Themen plauschen? Denn ist ja
> nicht wirklich Mac-spezifisch und ich habe immer ein schlechtes Gewissen,
> wenn wir uns hier mit dem DTP-Kram breitmachen...
Nachdem ja zwischenzeitlich einige Leute Ihr Interesse am Thema bekundet
haben, wäre ich dafür, dass wir es uns zunächst mal hier gemütlich
machen ...
Ciao
Achim,
der jetzt die Couch ansteuert, um sich der MiB II-DVD zu widmen ;-)
Thomas Kaiser
<news:1fpb8tk.14ifs721wmevy0N%use...@dtpd.com>:
[MS Publisher Output]
> Lauter gerade (!) Linien. Mehr sog I ned ;-)
Letzten Endes läuft es immer auf gerade Linien raus. Die müssen halt bloß
fein genug aneinander geklebt sein, damit man sie als rund wahrnimmt.
Und daß der Flattening Wert immer für eine Überraschung gut ist, wissen wir
PostScript-Haserl ja schon seit 15 Jahren oder länger :-)
> Die Seiten werden in der Druckerei mit ASURA und SOLVERO weiterverarbeitet,
> und erst da zeigt sich der besagte Fehler.
Und wenn sie da mal *ohne* die OneVision Software weiterverarbeiten würden?
BTW: Ich stehe dem Ansatz, alles, was an PS/PDF hereinkommt erstmal blind
via OneVision Tools zu "normalisieren" nicht unbedingt nur positiv
gegenüber.
> Ich hatte damals ein paar Mails mit dem (sehr kompetenten) Support von
> OneVision ausgetauscht, aber ad hoc ließ sich auch nicht herausfinden,
> ob nicht möglicherweise da der Fehler steckt.
Auch nicht, wenn Ihr die Dateien denen zugeschickt hättet (oder habt?)
Naja, die Unfehlbarkeitsvermutung hinsichtlich OneVision habe ich schon vor
ein paar Jahren revidieren müssen, als ein CtP-Studio händeringend darum
bat, PS-Files per CtF in der Klitsche, in der ich damals beschäftigt war,
auszubelichten. Bloss leider brachen die immer mit Fehlern ab. Letzten Endes
habe ich das dann irgendwann an defekten Schriften festmachen können, die
durch Asura in die Datei eingebettet wurden. Naja, zum Glück gibt es
Editoren ohne Grössenbegrenzung, in denen man sowas dann manuell grade
ziehen kann.
> [...] sag' doch mal: Was würdest Du denn von Pitstop-Server halten? Könnte
> das helfen?
Ich persönlich halte den für sehr sinnvoll. Wenn man Ausgabeworkflows
definiert, sollte man das Durchschleifen durch entsprechende Hotfolder nicht
vergessen. Nicht nur wegen den Prüffunktionen sondern auch, weil man bspw.
die 100 beliebtesten Flüchtigkeitsfehler via Aktionslisten automatisch
abfangen kann (bspw. die beliebte Variante mit weißen Schriftzügen, die auf
überdrucken stehen :-)
> Ich hatte mich nur darüber gewundert, dass es eine EPS-Datei
> schafft, auch "fremden" PS-Code in der Ganzseiten-Datei zu verändern.
Das ist kein "fremder" Code, sondern Metainformationen, die von
Adobe-Produkten gerne mal mitgeschleift werden (bspw. indem die MediaBox in
einem PDF beim Export in EPS als entsprechendes PDFMark definiert wird, was
anschl. wiederum dafür sorgt, daß bei erneutem Destillieren *exakt* diese
Mediabox gesetzt wird. "Eigentlich" wäre es Aufgabe der importierenden
Applikation derlei unschädlich zu machen bzw. die jeweiligen Boxen
entsprechend ihrer Aufgabe richtig zu interpretieren...
Aber das darf man bspw. von XPress nicht erwarten (ich bin erst letzte Woche
wieder über ein Problem im Zusammenhang mit Xpress gestolpert, bei dem
Xpress 4.x einfach abschmiert, wenn es in zu platzierenden Bildern auf
"Adobe Resource Blocks" stösst, die in einer für Xpress nicht genehmen
Reihenfolge daherkommen; derweil ist die Reihenfolge nirgends festgelegt,
inzwischen aber de facto durch Quark definiert, weil alle Softwares
natürlich an dieses dolle Programm und seine Fehler angepasst werden
*müssen*)
> Aber da sind wir wieder beim Thema "PS ist eine Programmiersprache" ...
Yo. Hatte vor ein paar Tagen eine Grafikerin hier und der mal ein paar
Grundlagen nähergebracht. Und weil sich's anbot, diese Thematik zu
besprechen und zu zeigen, was man mit PDFMarks alles anstellen kann,
entstand dann dieses EPS hier:
<http://users.phg-online.de/tk/images/fraktal.eps.sit>
Einfach mal irgendwo platzieren oder solo destillieren und dabei mal die
Programmzeile, die die Anzahl der Iterationen bestimmt, variieren
/iterate 9 def
(und dann die Auswirkungen in Hinsicht auf Interpretationszeit, PDF-Grösse
und Rendergeschwindigkeit seitens Acrobat beachten)
Übrigens: Man kann den Wert getrost auf mehr als 10 setzen, auch wenn im
Sourcecode warnend "any more that 10 will take ages" angemerkt wird. Daraus
sind im Vergleich zu 1989 (von da stammt der PS-Code) heute Sekunden bzw.
Minuten geworden :-)
Gruss,
Thomas, müde -- 2 Tage Kundentermine schlauchen
Thomas Kaiser
<news:1fpb8tk.14ifs721wmevy0N%use...@dtpd.com>:
> Genau. Wir haben früher selbst belichtet bzw. separierte PS-Files
> verschickt, was auch bei 4-Kanal-Übertragung satte Übertragungszeiten
> liefert.
Deshalb haben die besseren Print-/OPI-Server Kombinationen Mittelchen
eingebaut, mit denen Du bspw. direkt im PostScript Stream die Bilddaten
komprimieren kannst (analog zum Distiller bspw. Farb- und Graustufenbilder
per JPEG und 1 Bit Strichabbildungen per CCITT Group 4) und ggf. auch die
Auflösung anpassen kannst, d.h. ein Downsampling durchführen lässt.
> Deshalb, und auch auf Drängen der Druckereien (die endlich die
> Seitenkleber entlassen wollten, Bäh!)
Wobei die Bogenmonteure dann ja wohl Glück gehabt hatten, daß seitens
Druckerei niemand kapiert hat, daß man auch schon mit PS-Dateien
elektronische Ganzbogenmontage realisieren konnte.
> haben wir dann zu Composite-PDF gewechselt.
...und in dem Zug den eigentlich krasseren Schritt mit der Umstellung von
separiert auf composite vollzogen habt. Ob man nämlich nun einfach nur
PostScript ausliefert oder PDF ist eigentlich kein grosser Unterschied
(abgesehen von den paar Details, die wir in dem Thread schon anschnitten).
Aber von separiert auf composite umzustellen, zeigt ziemlich schnell die
Unzulänglichkeiten der verwendeten Software auf.
Auch in so einem Fall macht sich so ein mitdenkender Server bezahlt. Einfach
Feindaten auf den Server klatschen und mit den generierten Grobbildern
arbeiten. Anschl. muß man sich weder fürchten, daß bei Verwendung von DCS
Bildern (die berühmten 4 einzelnen Farbauszüge mit dem 5. composite
Übersichtsbild) in einem composite Workflow evtl. nur die 72 dpi Preview am
Ziel ankommt oder man bei Verwendung von JPEG-komprimierten 1-File EPS in
XPress nach einer separierten Ausgabe Farbbilder nur noch im Schwarzauszug
hat. Um all den Kram kümmert sich der Server heimlich still und leise :-)
>>> Völlig richtig. Und vermutlich war ich einer der ersten *g*, der die
>>> HELIOS Public Beta installiert und getestet hat. Nur richtig brauchen tu
>>> ich das Teil nicht,
>>
>> Naja, Dir hat halt noch niemand mit leicht glasigen Augen vorgeschwärmt und
>> gezeigt, was man alles für abgefahrene Sachen machen kann. Viele Perlen
>> stecken unter der Haube und die nimmt man bei einem oberflächlichen Test gar
>> nicht wahr. Aber egal...
>
> Ich hab' mir mal einen Teil des Manuals reingezogen, in dem die ganzen
> Parameter beschrieben sind, insbesondere auch die, die nicht über ein
> GUI erreichbar sind.
Das ist schon wirklich eine Menge. Deshalb finde ich es ja auch gut, daß
viele Sachen auch nicht per GUI erreichbar sind, sondern eben nur nach
Lektüre der Manuals, da das die "wild klicken ohne Nachdenken" Fraktion vor
allem vor sich selbst schützt. Das nette ist ja, daß der Server auch ohne
Kenntnis der Tuning-Parameter erst mal aus dem Stand heraus einfach läuft
und tut, was er tun soll. Und das teilweise so unauffällig, daß mir schon
Installationen untergekommen sind, in denen die Leute nach 3 Jahren erst
merkten, daß da ein Server stand (weil ein paar "Drucker" auf "mysteriöse"
Art verschwunden waren -- die Spooler waren halt weg, weil die kleine Ultra
nach mehr als 1000 Tagen Uptime einfach mal 'ne Auszeit wollte)
> Das ist alles ziemlich komplex,
Das spiegelt IMO bloß die Komplexität der in der Branche verwendeten
Technologien wieder. Das aber netterweise eben ziemlich umfassend.
> aber die Möglichkeiten sind mit Sicherheit fantastisch, wenn man etwas in
> die Tiefe geht.
Aber hat Dir schon mal jemand ganz simpel und ohne großartig auf die
technischen Details einzugehen gezeigt, wie man durch Adaption der
OPI-Techniken Aufwand sparen kann und Terminsituation prächtig entschärfen
kann?
Viele sehen das immer erstmal als sture Auseinandersetzung mit Technik
anstatt das Augenmerk einfach auf die Funktionalität und die Möglichkeit,
Arbeitsabläufe entspannter angehen zu können, zu legen.
[Create-PDF]
> Klar ist das alles sehr komfortabel und performant gelöst. Allerdings
> laufen bei uns ca. 99 von 100 ps-Files sauber durch, und nur eines
> spuckt ein log aus. Das kriegt man auch noch per Hand in den Griff ;-)
Schon klar. Wenn man dann noch die entsprechenden Tricks kennt, wie bspw.
Erhöhung des "/ImageMemory" Wertes auf 75% des dem Distiller zugeteilten RAM
(in den joboptions einzustellen), dann kann man bei geringen oder mittleren
Durchsatzanforderungen schon auf solche Sachen verzichten.
Allerdings war für mich diese Schnittstelle mit Hotfoldern bisher immer noch
ein Dorn im Auge, speziell wenn man Spitzenzeiten abzufangen hat (in dem
letzten Laden, in dem ich in Festanstellung arbeitete, wurde Kataloge für
CtP vorbereitet, das hieß zum Teil die Anforderung von einige tausend
HighRes PDFs pro Tag). Die Konfiguration der Hotfolder ist umständlich und
fehlerträchtig (spätestens wenn man mehr als einen Distiller laufen hat) und
das Überwachen des out Ordners auf .log Dateien ist so ein Moment, wo es
einfach absurd wird, wenn Menschen das Ergebnis von Maschinen "pollen"
müssen. Entspricht überhaupt nicht meiner Arbeitsphilosohpie, die darauf
abzielt, die Operators frei von technischen Zwängen zu machen, damit sie
sich auf ihre individuelle Kernkompetenz konzentrieren können. Und dazu
gehört eben auch, daß die Maschine anklopft, wenn was schief gelaufen ist
und nicht, daß Operators als Anhängsel der Maschine permanent gucken müssen.
>>> Das Konzept und die Leistungsfähigkeit von HELIOS sind genial, aber
>>> unsere Abläufe würden davon nicht wesentlich profotieren.
>>
>> Ich würde mich ja fast auf eine Wette einlassen. Bist Du ein fairer
>> Verlierer?
Das war übrigens ein saublöder Vorschlag meinerseits. Ein aktueller Kunde
hat das ebenfalls gelesen und kam schon auf die Idee, das auch aufs
Projektgeschäft anzuwenden ("Wetten daß wir nachher nicht doppelt so
produktiv sind"). Aber das konnten wir zwischenzeitlich wieder klären :-)
> Ja, bin ich. Aber es kommt auf den Blickwinkel an: Bezüglich Komfort,
> Performance und Produktionssicherheit gebe ich Dir Recht. Die
> Kosten-/Nutzen-Analyse spricht aber bei unserem momentanen Durchsatz
> (den Du natürlich von außen nicht beurteilen kannst) dagegen.
Klar, das mit dem aktuellen Durchsatz kann man von extern betrachtet nicht
wissen. Aber Du schriebst ja oben davon, daß Eure *Abläufe* nicht
profitieren könnten. Und das will mir nicht so recht in den Kopf, denn das
würde eigentlich bedeuten, daß Ihr nur Chaoten habt, denen man nicht mehr
helfen kann.
Ich musste bspw. neulich herzhaft lachen, als ich in AFAIR der Publishing
Praxis in einem Anwenderbericht über eine Reprofirma bei München, die Xinet'
FullPress einsetzen, lesen durfte, daß sie im Vergleich zur Arbeit mit
Helios OPI doppelt so produktiv geworden sind durch das FullPress eigene
Feature, daß die Grobdaten quasi immer nur eine andere Sicht auf die
Feindaten darstellen und somit niemals "verwaiste" Grobdaten auf nicht mehr
existente Feindaten zeigen können, die dann bei der Ausgabe Probleme machen.
Wenn das wirklich der Fall ist, dann sollten mal die Abläufe überdacht
werden. Denn wenn anscheinend schon mindestens die Hälfte der Belegschaft
den ganzen Tag nur Bilder verschiebt, damit sie anschl. nicht mehr gefunden
werden, dann ist das sicherlich der lohnendere Ansatz, da mal nachzubohren,
ob da nicht sowas wie eine einfach nachvollziehbare Struktur auf dem Server
fehlt.
> Insofern steht es 3:1 für Dich, und damit gewinnst Du so viele
> Waschmaschinen, wie Du tragen kannst ;-)
Mit Rücksicht auf mein Kreuz gehe ich also mal wieder leer aus ;-(
Können wir uns nicht auf *schwere* Digitalkameras nebst passenden Objektiven
einigen? EOS D1s oder DCS Pro 14n oder was in der Gewichtsklasse. Ich achte
auch auf den Rat des Orthopäden und nehm nicht zu viele, okay? ;-))
Gruss,
Thomas
Achim Denzl
> Achim Denzl schrieb am 24.01.2003 22:38 Uhr in
> <news:1fpb8tk.14ifs721wmevy0N%use...@dtpd.com>:
>
> [MS Publisher Output]
> > Lauter gerade (!) Linien. Mehr sog I ned ;-)
>
> Letzten Endes läuft es immer auf gerade Linien raus. Die müssen halt bloß
> fein genug aneinander geklebt sein, damit man sie als rund wahrnimmt.
Yepp. Wobei AFAIK zumindest bei Belichtern die Linie zum Teil so kurz
sind, dass man fast schon von Punkten sprechen könnte.
> Und daß der Flattening Wert immer für eine Überraschung gut ist, wissen wir
> PostScript-Haserl ja schon seit 15 Jahren oder länger :-)
Besonders lustig war's damals(TM), ein Linotronic RIP 30 mit einem
Photoshop-EPS mit einer Kurvernnäherung von 0,5 ins Jenseits zu
befördern. Diese hübschen Rauchwölkchen ;-)
> > Die Seiten werden in der Druckerei mit ASURA und SOLVERO weiterverarbeitet,
> > und erst da zeigt sich der besagte Fehler.
>
> Und wenn sie da mal *ohne* die OneVision Software weiterverarbeiten würden?
Das geht nicht, da deren RIP keine PDFs direkt verarbeiten kann. Deshalb
werden die ankommenden PDF-Files in EPS re-konvertiert und dann
belichtet.
> BTW: Ich stehe dem Ansatz, alles, was an PS/PDF hereinkommt erstmal blind
> via OneVision Tools zu "normalisieren" nicht unbedingt nur positiv
> gegenüber.
Warum? Meistens ist es doch sehr beruhigend, wenn man weiss, dass die
Dateien fehlerfrei sind. Ich hatte früher mal mit Tailor und AppleScript
einen Hotfolder-basierten EPS-Cleaner gebastelt, da Tailor beim
Neu-sichern eines EPS auch den ganzen Müll aus dem EPS rausfiltert.
Funktionierte ganz gut, nut leider war Tailor dem geforderten Durchsatz
nicht gewachsen ...
> > Ich hatte damals ein paar Mails mit dem (sehr kompetenten) Support von
> > OneVision ausgetauscht, aber ad hoc ließ sich auch nicht herausfinden,
> > ob nicht möglicherweise da der Fehler steckt.
>
> Auch nicht, wenn Ihr die Dateien denen zugeschickt hättet (oder habt?)
Doch, doch, habe ich. Zumal OneVision ja auch bei uns um die Ecke ist.
Ich weiss jetzt gar nicht, was dabei raus kam (ist schon eine Zeitlang
her). Das Problem ist zwischenzeitlich behoben, allerdings weiss ich
wirklich nicht mehr, ob wir da was gedreht haben oder ob OV mit einem
kleinen Patch reagiert hat ...
> Naja, die Unfehlbarkeitsvermutung hinsichtlich OneVision habe ich schon vor
> ein paar Jahren revidieren müssen, als ein CtP-Studio händeringend darum
> bat, PS-Files per CtF in der Klitsche, in der ich damals beschäftigt war,
> auszubelichten. Bloss leider brachen die immer mit Fehlern ab. Letzten Endes
> habe ich das dann irgendwann an defekten Schriften festmachen können, die
> durch Asura in die Datei eingebettet wurden. Naja, zum Glück gibt es
> Editoren ohne Grössenbegrenzung, in denen man sowas dann manuell grade
> ziehen kann.
Bei der Komplexität der Materie wird wohl ein 100%ig wasserdichter
PS-Editor nie zu realisieren sein. Bei PDF sieht's da vermutlich schon
etwas besser aus ;-)
> > [...] sag' doch mal: Was würdest Du denn von Pitstop-Server halten? Könnte
> > das helfen?
>
> Ich persönlich halte den für sehr sinnvoll. Wenn man Ausgabeworkflows
> definiert, sollte man das Durchschleifen durch entsprechende Hotfolder nicht
> vergessen. Nicht nur wegen den Prüffunktionen sondern auch, weil man bspw.
> die 100 beliebtesten Flüchtigkeitsfehler via Aktionslisten automatisch
> abfangen kann (bspw. die beliebte Variante mit weißen Schriftzügen, die auf
> überdrucken stehen :-)
Gottseidank kann man dieses Problem dank der Überdrucken-Vorschau in
Acrobat 5 mittlerweile zumindest visuell entdecken. Bei Postscript gab's
immer erst hiinterher große Augen und händeringed Erklärungsversuche ;-)
> > Ich hatte mich nur darüber gewundert, dass es eine EPS-Datei
> > schafft, auch "fremden" PS-Code in der Ganzseiten-Datei zu verändern.
>
> Das ist kein "fremder" Code, sondern Metainformationen, die von
> Adobe-Produkten gerne mal mitgeschleift werden (bspw. indem die MediaBox in
> einem PDF beim Export in EPS als entsprechendes PDFMark definiert wird, was
> anschl. wiederum dafür sorgt, daß bei erneutem Destillieren *exakt* diese
> Mediabox gesetzt wird. "Eigentlich" wäre es Aufgabe der importierenden
> Applikation derlei unschädlich zu machen bzw. die jeweiligen Boxen
> entsprechend ihrer Aufgabe richtig zu interpretieren...
Das ist Ansichtssache. Mir persönlich ist es lieber, dass das
Anwendungsprogramm _nicht_ in externe Dateien eingreift, sondern - ala
QXP - diese einfach 1:1 zum Ausgabegerät durchschiebt.
> Aber das darf man bspw. von XPress nicht erwarten (ich bin erst letzte Woche
> wieder über ein Problem im Zusammenhang mit Xpress gestolpert, bei dem
> Xpress 4.x einfach abschmiert, wenn es in zu platzierenden Bildern auf
> "Adobe Resource Blocks" stösst, die in einer für Xpress nicht genehmen
> Reihenfolge daherkommen; derweil ist die Reihenfolge nirgends festgelegt,
> inzwischen aber de facto durch Quark definiert, weil alle Softwares
> natürlich an dieses dolle Programm und seine Fehler angepasst werden
> *müssen*)
Ja, QXP's Auslegung von Postscript ist schon etwas eigen. Aber es hat
alles seine Vor- und Nachteile. Meiner Erfahrung nach ist der von QXP
erzeugte PS-Stream hinsichtlich RIP-Geschwindigkeit und Effizienz bisher
ungeschlagen. Allerdings wohl nicht mehr völlig Adobe-PS-konform;
während unsere Ausgabegeräte das alles wunderbar verdauen, kommt Tailor
mit Quark 4-Postscript in den meisten Fällen nicht mehr zurecht ;-(
> > Aber da sind wir wieder beim Thema "PS ist eine Programmiersprache" ...
>
> Yo. Hatte vor ein paar Tagen eine Grafikerin hier und der mal ein paar
> Grundlagen nähergebracht. Und weil sich's anbot, diese Thematik zu
> besprechen und zu zeigen, was man mit PDFMarks alles anstellen kann,
> entstand dann dieses EPS hier:
>
> <http://users.phg-online.de/tk/images/fraktal.eps.sit>
>
> Einfach mal irgendwo platzieren oder solo destillieren und dabei mal die
> Programmzeile, die die Anzahl der Iterationen bestimmt, variieren
>
> /iterate 9 def
>
> (und dann die Auswirkungen in Hinsicht auf Interpretationszeit, PDF-Grösse
> und Rendergeschwindigkeit seitens Acrobat beachten)
Im Moment verfüttere ich das gerade an Tailor, allerdings mit einer
Iteration von 20. Das scheint zu dauern. Manchmal hat OS X dann doch
wieder Vorteile ;-)
Dem Distiller werde ich es dann später mal auferlegen ...
[Ah, Tailor hat's gerade zerbröselt, zu wenig Arbeitsspeicher]
> Thomas, müde -- 2 Tage Kundentermine schlauchen
Na dann ab ins Bett! Falls es Dich tröstet, ich muss heute auch noch ins
Büro, Spätschicht ;-(
Ciao
Achim
--
OS X:
"System shutdown time has arrived
but you'll have to do it yourself"
Achim Denzl
> > Einfach mal irgendwo platzieren oder solo destillieren und dabei mal die
> > Programmzeile, die die Anzahl der Iterationen bestimmt, variieren
> >
> > /iterate 9 def
> >
> > (und dann die Auswirkungen in Hinsicht auf Interpretationszeit, PDF-Grösse
> > und Rendergeschwindigkeit seitens Acrobat beachten)
>
> Im Moment verfüttere ich das gerade an Tailor, allerdings mit einer
> Iteration von 20. Das scheint zu dauern. Manchmal hat OS X dann doch
> wieder Vorteile ;-)
>
> Dem Distiller werde ich es dann später mal auferlegen ...
>
> [Ah, Tailor hat's gerade zerbröselt, zu wenig Arbeitsspeicher]
Der Distiller packt's übrigens auch nicht. Erst ab 15 oder kleiner :-/
Achim Denzl
> Achim Denzl schrieb am 24.01.2003 22:38 Uhr in
> <news:1fpb8tk.14ifs721wmevy0N%use...@dtpd.com>:
>
> > Genau. Wir haben früher selbst belichtet bzw. separierte PS-Files
> > verschickt, was auch bei 4-Kanal-Übertragung satte Übertragungszeiten
> > liefert.
>
> Deshalb haben die besseren Print-/OPI-Server Kombinationen Mittelchen
> eingebaut, mit denen Du bspw. direkt im PostScript Stream die Bilddaten
> komprimieren kannst (analog zum Distiller bspw. Farb- und Graustufenbilder
> per JPEG und 1 Bit Strichabbildungen per CCITT Group 4) und ggf. auch die
> Auflösung anpassen kannst, d.h. ein Downsampling durchführen lässt.
Allerdings setzt das immer einen Server voraus, direkt aus dem
Anwendungsprogramm ist das nicht möglich. Wir haben die ps-Dateien dann
vor dem Versand gestufft, das sparte nochmal mindestens die Hälfte an
Platz. Eine interne JPEG-Kompression wäre da allerdings effektiver,
zugegeben ...
> > Deshalb, und auch auf Drängen der Druckereien (die endlich die
> > Seitenkleber entlassen wollten, Bäh!)
>
> Wobei die Bogenmonteure dann ja wohl Glück gehabt hatten, daß seitens
> Druckerei niemand kapiert hat, daß man auch schon mit PS-Dateien
> elektronische Ganzbogenmontage realisieren konnte.
Klar, aber damals kamen auch noch nicht alle Vorlagen in digitaler Form,
so dass unter Umständen eine manuelle Montage unumgänglich war oder
zumindest rentabler als die Anschaffung eines entsprechenden
Copydot-Scanners für Farbsätze.
> > haben wir dann zu Composite-PDF gewechselt.
>
> ...und in dem Zug den eigentlich krasseren Schritt mit der Umstellung von
> separiert auf composite vollzogen habt. Ob man nämlich nun einfach nur
> PostScript ausliefert oder PDF ist eigentlich kein grosser Unterschied
> (abgesehen von den paar Details, die wir in dem Thread schon anschnitten).
> Aber von separiert auf composite umzustellen, zeigt ziemlich schnell die
> Unzulänglichkeiten der verwendeten Software auf.
Falls du damit auf die fehlenden Überfüllungsdaten in Quark-Compsites
anspielst, so ist das natürlich ein Problem. Aber zumindest kommen
zwischenzeitlich immerhin die Überdrucken-Tags mit durch, und um den
Rest sollte sich eigentlich das InRIP-Trapping kümmern.
> Auch in so einem Fall macht sich so ein mitdenkender Server bezahlt. Einfach
> Feindaten auf den Server klatschen und mit den generierten Grobbildern
> arbeiten. Anschl. muß man sich weder fürchten, daß bei Verwendung von DCS
> Bildern (die berühmten 4 einzelnen Farbauszüge mit dem 5. composite
> Übersichtsbild) in einem composite Workflow evtl. nur die 72 dpi Preview am
> Ziel ankommt oder man bei Verwendung von JPEG-komprimierten 1-File EPS in
> XPress nach einer separierten Ausgabe Farbbilder nur noch im Schwarzauszug
> hat. Um all den Kram kümmert sich der Server heimlich still und leise :-)
Kann Dein hochgelobter H****S-Server eigentlich auch separierte PS- oder
PDF-Files zu Composite zusammensetzen?
> > Ich hab' mir mal einen Teil des Manuals reingezogen, in dem die ganzen
> > Parameter beschrieben sind, insbesondere auch die, die nicht über ein
> > GUI erreichbar sind.
>
> Das ist schon wirklich eine Menge. Deshalb finde ich es ja auch gut, daß
> viele Sachen auch nicht per GUI erreichbar sind, sondern eben nur nach
> Lektüre der Manuals, da das die "wild klicken ohne Nachdenken" Fraktion vor
> allem vor sich selbst schützt. Das nette ist ja, daß der Server auch ohne
> Kenntnis der Tuning-Parameter erst mal aus dem Stand heraus einfach läuft
> und tut, was er tun soll. Und das teilweise so unauffällig, daß mir schon
> Installationen untergekommen sind, in denen die Leute nach 3 Jahren erst
> merkten, daß da ein Server stand (weil ein paar "Drucker" auf "mysteriöse"
> Art verschwunden waren -- die Spooler waren halt weg, weil die kleine Ultra
> nach mehr als 1000 Tagen Uptime einfach mal 'ne Auszeit wollte)
Nur mal so interessehalber, bevor ich der Promo GmbH auf den Wecker
falle: Für die kleinste (Nutzerzahl) HELIOS-Lösung, bestehend aus
EtherShare, EtherShare OPI und PDF-Handshake, welche ungefähre Summe
sollte man da einplanen?
( ) 1500 Euro
( ) 3000 Euro
( ) 5000 Euro
( ) 7500 Euro
> > Das ist alles ziemlich komplex,
>
> Das spiegelt IMO bloß die Komplexität der in der Branche verwendeten
> Technologien wieder. Das aber netterweise eben ziemlich umfassend.
>
> > aber die Möglichkeiten sind mit Sicherheit fantastisch, wenn man etwas in
> > die Tiefe geht.
>
> Aber hat Dir schon mal jemand ganz simpel und ohne großartig auf die
> technischen Details einzugehen gezeigt, wie man durch Adaption der
> OPI-Techniken Aufwand sparen kann und Terminsituation prächtig entschärfen
> kann?
>
> Viele sehen das immer erstmal als sture Auseinandersetzung mit Technik
> anstatt das Augenmerk einfach auf die Funktionalität und die Möglichkeit,
> Arbeitsabläufe entspannter angehen zu können, zu legen.
Ich sehe das in unserem Fall zunächst mal von der Kosten-/Nutzen-Seite.
Unser ASIP-Server ist ausreichend dimensioniert, und unser Workflow ist
im Rahmen der Möglichkeiten bestmöglich automatisiert und optimiert.
Die Rechnung lautet also: Wieviel an (Lohn-) Kosten kann ich durch
Einsatz eines entsprechenden Servers einsparen, und in welchem Zeitraum
amortisiert sich auf dieser Grundlage die Anschaffung.
Bei unseren größeren Produktionen (die prinzipiell am ehesten davon
profitieren könnten), sehe ich keinen großen Nutzen, da unsere Techniker
so gut wie nie auf die Technik, aber häufig auf Input vom Kunden warten
müssen. Und dann würde eine Investition in schnellere Technologie nur
dazu führen, dass die Leerlaufzeiten zunehmen, ohne am gesamten
Zeitaufwand etwas zu ändern.
> [Create-PDF]
> > Klar ist das alles sehr komfortabel und performant gelöst. Allerdings
> > laufen bei uns ca. 99 von 100 ps-Files sauber durch, und nur eines
> > spuckt ein log aus. Das kriegt man auch noch per Hand in den Griff ;-)
>
> Schon klar. Wenn man dann noch die entsprechenden Tricks kennt, wie bspw.
> Erhöhung des "/ImageMemory" Wertes auf 75% des dem Distiller zugeteilten RAM
> (in den joboptions einzustellen), dann kann man bei geringen oder mittleren
> Durchsatzanforderungen schon auf solche Sachen verzichten.
Und wo wird das RAM abgezweigt? Ich kenne das nur von unserem Viper-RIP,
wo es einen Schieberegler gibt, den ich von "Vektor Graphics" bis hin zu
"Images" schieben kann. Einen großen Unterschied macht das allerdings
nicht ...
> Allerdings war für mich diese Schnittstelle mit Hotfoldern bisher immer noch
> ein Dorn im Auge, speziell wenn man Spitzenzeiten abzufangen hat (in dem
> letzten Laden, in dem ich in Festanstellung arbeitete, wurde Kataloge für
> CtP vorbereitet, das hieß zum Teil die Anforderung von einige tausend
> HighRes PDFs pro Tag). Die Konfiguration der Hotfolder ist umständlich und
> fehlerträchtig (spätestens wenn man mehr als einen Distiller laufen hat) und
> das Überwachen des out Ordners auf .log Dateien ist so ein Moment, wo es
> einfach absurd wird, wenn Menschen das Ergebnis von Maschinen "pollen"
> müssen. Entspricht überhaupt nicht meiner Arbeitsphilosohpie, die darauf
> abzielt, die Operators frei von technischen Zwängen zu machen, damit sie
> sich auf ihre individuelle Kernkompetenz konzentrieren können. Und dazu
> gehört eben auch, daß die Maschine anklopft, wenn was schief gelaufen ist
> und nicht, daß Operators als Anhängsel der Maschine permanent gucken müssen.
In der von Dir geschilderten Größenordnung gebe ich Dir uneingeschränkt
Recht. Ich habe aber bewußt eine Zwischenstufe eingebaut, um alle
PDF-Files vor dem Versand nochmal in Acrobat zu begutachten; mit anderen
Worten müssen die Techniker sowieso den Out-Ordner öffnen, um die
PDF-Datei zu öffnen. Da fällt eine .log-Datei in jedem Fall auf. Und in
diesem Out-Ordner liegt wiederum ein GrandCentral-Hotfolder, so dass
nach Freigabe der Seite durch den Techniker dieser die Seite einfach in
den nächsten Ordner veschiebt. Job done ;-)
> >>> Das Konzept und die Leistungsfähigkeit von HELIOS sind genial, aber
> >>> unsere Abläufe würden davon nicht wesentlich profotieren.
> >>
> >> Ich würde mich ja fast auf eine Wette einlassen. Bist Du ein fairer
> >> Verlierer?
>
> Das war übrigens ein saublöder Vorschlag meinerseits. Ein aktueller Kunde
> hat das ebenfalls gelesen und kam schon auf die Idee, das auch aufs
> Projektgeschäft anzuwenden ("Wetten daß wir nachher nicht doppelt so
> produktiv sind"). Aber das konnten wir zwischenzeitlich wieder klären :-)
*LOL*
> > Ja, bin ich. Aber es kommt auf den Blickwinkel an: Bezüglich Komfort,
> > Performance und Produktionssicherheit gebe ich Dir Recht. Die
> > Kosten-/Nutzen-Analyse spricht aber bei unserem momentanen Durchsatz
> > (den Du natürlich von außen nicht beurteilen kannst) dagegen.
>
> Klar, das mit dem aktuellen Durchsatz kann man von extern betrachtet nicht
> wissen. Aber Du schriebst ja oben davon, daß Eure *Abläufe* nicht
> profitieren könnten. Und das will mir nicht so recht in den Kopf, denn das
> würde eigentlich bedeuten, daß Ihr nur Chaoten habt, denen man nicht mehr
> helfen kann.
>
> Ich musste bspw. neulich herzhaft lachen, als ich in AFAIR der Publishing
> Praxis in einem Anwenderbericht über eine Reprofirma bei München, die Xinet'
> FullPress einsetzen, lesen durfte, daß sie im Vergleich zur Arbeit mit
> Helios OPI doppelt so produktiv geworden sind durch das FullPress eigene
> Feature, daß die Grobdaten quasi immer nur eine andere Sicht auf die
> Feindaten darstellen und somit niemals "verwaiste" Grobdaten auf nicht mehr
> existente Feindaten zeigen können, die dann bei der Ausgabe Probleme machen.
>
> Wenn das wirklich der Fall ist, dann sollten mal die Abläufe überdacht
> werden. Denn wenn anscheinend schon mindestens die Hälfte der Belegschaft
> den ganzen Tag nur Bilder verschiebt, damit sie anschl. nicht mehr gefunden
> werden, dann ist das sicherlich der lohnendere Ansatz, da mal nachzubohren,
> ob da nicht sowas wie eine einfach nachvollziehbare Struktur auf dem Server
> fehlt.
Das stimmt allerdings: Ordnung ist das halbe Leben, zumindest was die
Strukturen auf Servern anbelangt ;-)
Wobei mir die Datei-Doppelung bei HELIOS auch nicht sonderlich behagt.
Mir fehlt da immer ein bisschen das Vertrauen in die OPI-Server und die
entsprechenden Konzepte. Wenn ich Bild X in QXP lade, dann will ich auch
Bild X im Output haben. Und spätestens bei der Weitergabe von offenen
QXP-Dateien wird's wieder schwierig, trotz OPI-Swapper XT und ähnlichen
Geschichten. Aber das ist vermutlich alles eine Frage eines stimmigen
Workflow-Konzepts und einer gewissen Eingewöhung ;-)
> > Insofern steht es 3:1 für Dich, und damit gewinnst Du so viele
> > Waschmaschinen, wie Du tragen kannst ;-)
>
> Mit Rücksicht auf mein Kreuz gehe ich also mal wieder leer aus ;-(
Naja, eine Tasse Kaffee würde ich troztzdem springen lassen ;-)
> Können wir uns nicht auf *schwere* Digitalkameras nebst passenden Objektiven
> einigen? EOS D1s oder DCS Pro 14n oder was in der Gewichtsklasse. Ich achte
> auch auf den Rat des Orthopäden und nehm nicht zu viele, okay? ;-))
<Raspel, krächz> Hallo? Hallooooo? Die Verbindung ist s schlht. I kan S
grnch mr rchttg vrsthen <Tuuut, tuuut, tuuut>
Achim Denzl
> > Schon klar. Ich hatte mich nur darüber gewundert, dass es eine EPS-Datei
> > schafft, auch "fremden" PS-Code in der Ganzseiten-Datei zu verändern.
> > Aber da sind wir wieder beim Thema "PS ist eine Programmiersprache" ...
>
> Das wundert mich über nicht (ich habe schon in PS Programme
> geschrieben). EPSF sind bloß Codefragmente, die im restlichen PS
> Programm eingebettet sind. Wichtig ist dabei, daß man die PS VM so
> verläßt wie man sie zu Anfang vorgefunden hat. Wenn nicht gibt es üble
> Seiteneffekte.
Ah, ein PS-Guru *niederknie*. Vielleicht hast Du ja (eventuell kann auch
Thomas helfen ;-) eine Lösung für eine andere Idee meinerseits.
Ich möchte gerne den Distiller dazu bewegen, beim Destillieren einer
Einzelseite als PS- oder EPS-Datei ein statisches Hintergrundbild (liegt
auch als EPS oder PS vor) miteinzubeziehen.
Theoretisch sollte das unter Verwendung der Prolog/Epilog Datei möglich
sein. Grafisch betrachtet sieht das so aus:
+------------+ +------------+ +------------+
| xxxxxxx | | | | xxxxxxx |
| | | | | |
| | | | | |
| | | yy | | yy |
| | + | yyyy | = | yyyy |
| | | yyyy | | yyyy |
| | | | | |
| xxxxxxx | | | | xxxxxxx |
| xxxxxxx | | | | xxxxxxx |
+------------+ +------------+ +------------+
Statischer Aktuell Fertiges
Hintergrund destillierte PDF
im Prolog (E)PS-Datei
In der Basisversion würde es schon reichen, wenn die beiden
Ausgangsdateien "transparent" übereinandergelegt würden.
In der eigentlich nötigen "deLuxe"-Version wären die Anforderungen
allerdings noch etwas höher:
Es sollte (jeweils bezogen auf die zu destillierende Datei)
- der tatsächlich vorhandene Inhalt (nicht die gesamte page) mittig
platziert werden
- und nötigenfalls verkleinert werden, um Überdeckungen des
Hintergrundbildes zu verhindern
- und bei verkleinerter Darstellung noch ein kurzer, feststehender Text
mit ausgegeben werden
Bei genauerem Nachdenken fällt mir da bestimmt noch mehr ein ;-)
Wäre natürlich klasse, wenn jemand sowas schon in der Bastelkiste hätte.
Ansonsten sind natürlich sachdienliche Hinweise herzlich willkommen,
sofern sie nicht den lapidaren Hinweis auf das Adobe PS-Compendium
beinhalten. Denn das tu ich mir wirklich nicht an ;-)
Thomas Kaiser
<news:1fpebxt.1jvpd139cfd72N%use...@dtpd.com>:
[<http://users.phg-online.de/tk/images/fraktal.eps.sit>]
> Der Distiller packt's übrigens auch nicht. Erst ab 15 oder kleiner :-/
Yepp. Habe das vorhin bei ein paar Kunden über originale Adobe-RIPs,
Harlequin- und JAWS-Interpreter geschickt. Bei mehr als 15 landet es immer
im "errors" Ordner...
Einzig GhostScript 7 ist noch im Rennen. Ich lasse das jetzt noch ein
Stündchen laufen, dann gucken wir mal...
Gruss,
Thomas
Thomas Kaiser
<news:1fpeec6.t9f56oedrzdqN%use...@dtpd.com>:
> Ah, ein PS-Guru *niederknie*.
Lies mal ein bisserl in comp.lang.postscript mit. Das schafft erst recht
Ehrfurcht ;-)
> Es sollte (jeweils bezogen auf die zu destillierende Datei)
> - der tatsächlich vorhandene Inhalt (nicht die gesamte page) mittig
> platziert werden
> - und nötigenfalls verkleinert werden, um Überdeckungen des
> Hintergrundbildes zu verhindern
> - und bei verkleinerter Darstellung noch ein kurzer, feststehender Text
> mit ausgegeben werden
Ach, wie sich doch die Anforderungen gleichen. Zu Zeiten, als ich noch die
"Entwicklungsabteilung" eines Hamburger Consultants stellte (noch gar nicht
so lange her), durfte ich sowas mal realisieren.
Allerdings in der Weicheier-Variante mit PostScript-Templates, in denen dann
einfach durch Ausnutzung von OPI und PDF-Handshake und Austausch der Pfade
zu den Feinbildern (PDFs der Seiten) besagte Sachen passiert sind.
Ging um einen Sprachwechsler-Workflow, bei dem im Bedarfsfall noch die
relevanten Informationen aus PitStop Server Reporten mit auf den Proofs
erscheinen sollten (getrennt für Text- und Bild-PDF, wenn nötig)
Sowas hätte man auch in PostScript machen können aber der andere Weg
erschien mir damals simpler, weil die Randbedingungen eh schon stimmten
(musste eh alles auf dem Server passieren wegen fetten Datenmengen und
hohen Anforderungen an den Durchsatz).
> Bei genauerem Nachdenken fällt mir da bestimmt noch mehr ein ;-)
Sicher.
> Wäre natürlich klasse, wenn jemand sowas schon in der Bastelkiste hätte.
Meine Lösung qualifiziert sich bei Dir mangels Werkzeug, vermute ich ;-)
> Ansonsten sind natürlich sachdienliche Hinweise herzlich willkommen,
Siehe bspw. <news:3B0559...@srz-berlin.de>. Allerdings solltest Du die
epilogue.ps in Betracht ziehen, da das graphische Modell von PostScript
davon ausgeht, daß Seitenelemente, die zuerst gezeichnet werden unter den
nachfolgenden liegen. Die prologue.ps eignet sich also eher für
Wasserzeichen und Sachen, die hinter den aktuellen Seiten liegen.
Bei Deinen Spezialitäten wie Platzierung von Dingen hier und da wirst Du
aber auch den Ansatz vergessen können. Da heißt es dann in den sauren Apfel
beissen und entweder PostScript-Programmierung oder aber das hantieren mit
Templates (Hint: Gute PostScript-Programmierer sind eher rar; für das
programmiertechnische Umsetzen letzterer Lösung findet man aber
normalerweise auf jedem Schulhof einen Experten)
Gruss,
Thomas
Thomas Kaiser
[Downsampling und Bilddatenkomprimierung innerhalb PS-Stream]
> Allerdings setzt das immer einen Server voraus, direkt aus dem
> Anwendungsprogramm ist das nicht möglich.
Je nach Anwendung. Photoshop bspw. beherrscht es schon länger, Bilder
komprimiert in PostScript zu verpacken.
> Wir haben die ps-Dateien dann vor dem Versand gestufft, das sparte nochmal
> mindestens die Hälfte an Platz.
Das hässliche an externer Komprimierung ist aber, daß die gepackten Dateien
am Ziel wieder entpackt werden müssen. Bei Helios bspw. gibt es die
Möglichkeit, externe Komprimierung on-the-fly einzusetzen schon länger (5-6
Jahre IIRC). Dabei wird der Ausgabedatenstrom eben direkt per LZW oder ZIP
gepackt. Blöder Nebeneffekt: das dicke PostScript-File von bspw. 1,9 GByte
Grösse bereitet vielen Ausgabebetrieben massive Probleme, da es entpackt
mehr als 2 GByte hätte und damit an diverse Dateisystemlimitationen stösst.
> Eine interne JPEG-Kompression wäre da allerdings effektiver, zugegeben ...
Je nachdem (es gibt die motivabhängigen Spezialfälle, bei denen LZW- oder
ZIP-Kompression effektiver ist als DCT). Aber auch wenn es um verlustfreie
Kompression geht, ist die "interne" Komprimierung von Bilddaten IMO besser
(zumindest wenn das Ziel-RIP PostScript Level 2 und damit die nötigen InRIP
Dekodierungsroutinen beherrscht)
[Wechsel von separiertem Workflow auf Composite]
> Falls du damit auf die fehlenden Überfüllungsdaten in Quark-Compsites
> anspielst, so ist das natürlich ein Problem.
Das ist nur die Spitze des Eisberges. Ebenso die Probleme, die daraus
resultieren, daß Xpress mit PostScript Level 1 Methoden die onHost
Separation von EPS-Dateien probiert (und dabei regelmässig bei
JPEG-komprimierten EPS auf die Nase fällt). Oder Probleme mit Sonderfarben,
etc. etc.
> Kann Dein hochgelobter H****S-Server eigentlich auch separierte PS- oder
> PDF-Files zu Composite zusammensetzen?
PDF schon.
> Nur mal so interessehalber, bevor ich der Promo GmbH auf den Wecker
> falle: Für die kleinste (Nutzerzahl) HELIOS-Lösung, bestehend aus
> EtherShare, EtherShare OPI und PDF-Handshake, welche ungefähre Summe
> sollte man da einplanen?
> ( ) 1500 Euro
> ( ) 3000 Euro
> ( ) 5000 Euro
> ( ) 7500 Euro
[ ] Keine Ahnung (und Leitung inzwischen dicht, weil sich per wget ein paar
ISO-Images auf den Server quälen). Aber unter http://www.helios.de bist Du
nur wenige Klicks von einer Preisliste entfernt.
[OPI-Server einsetzen?]
> Ich sehe das in unserem Fall zunächst mal von der Kosten-/Nutzen-Seite.
Durchaus legitim. Kommt aber natürlich noch drauf an, was man machen will,
d.h. ob man bspw. das aktuelle Portfolio beibehalten will oder aber mehr
Durchsatz erreichen will, andere Segmente mit abdecken will, etc.
Ein Agenturkunde von mir hat bspw. vor einem Jahr (IIRC) sich von ASIP
verabschiedet und ist Richtung OPI-Server gegangen. In dem Jahr hat sich
viel getan und die Agentur macht inzwischen immer mehr Sachen, die früher
klassische externe Dienstleister gemacht haben. Überhaupt habe ich den
Eindruck, daß die klassischen Mediendienstleister sich zunehmend dagegen
wehren müssen, zwischen Agenturen und Druckereien, die beide immer weiter
vom Tätigkeitsfeld her in deren Bereich vorstossen, zermahlen zu werden.
Ich kenne eigentlich nur ganz wenige Betriebe überhaupt im grafischen
Gewerbe, die es geschafft haben, in den letzten drei Jahren ein nahezu
unverändertes Leistungsportfolio beizubehalten.
> Unser ASIP-Server ist ausreichend dimensioniert, und unser Workflow ist
> im Rahmen der Möglichkeiten bestmöglich automatisiert und optimiert.
Das ist schon viel wert.
> Die Rechnung lautet also: Wieviel an (Lohn-) Kosten kann ich durch
> Einsatz eines entsprechenden Servers einsparen, und in welchem Zeitraum
> amortisiert sich auf dieser Grundlage die Anschaffung.
Oder was kann ich noch alles damit anstellen; in welchen Bereichen kann ich
mich zusätzlich von anderen abheben?
Aber an genau der Stelle müssen v.a. auch die Menschen im Vordergrund
stehen: kann man mit einer technischen Lösung überhaupt den Mitarbeiterstamm
versorgen, der evtl. andere Arbeitsweisen gewöhnt ist und eine Vereinfachung
der ihn umgebenden Abläufe als Einschränkung wahrnimmt (mit den üblichen
Folgen schlechteres Arbeitsklima, Sinken der Produktivität, etc.)
> Bei unseren größeren Produktionen (die prinzipiell am ehesten davon
> profitieren könnten), sehe ich keinen großen Nutzen, da unsere Techniker
> so gut wie nie auf die Technik, aber häufig auf Input vom Kunden warten
> müssen.
Das klingt ziemlich paradiesisch bzw. danach, daß Ihr weder einen separate
Dateneingangsabteilung habt (IMO eh nur in Rieseninstallation annähernd
sinnvoll) oder aber durch Entzerrung von eigentlich aufeinanderfolgenden
Abläufen (ich wiederhole mich, ich weiß) durch OPI viel verschenkt ;-)
Soll ich eigentlich mal diesbzgl. ein Beispiel posten, damit ein wenig
klarer wird, von was ich da immer fabuliere?
> Und dann würde eine Investition in schnellere Technologie nur dazu führen,
> dass die Leerlaufzeiten zunehmen, ohne am gesamten Zeitaufwand etwas zu
> ändern.
Und wenn Du den Leuten das Vertrauen schenkst, daß sie mehr als einen
Auftrag pro Tag machen dürfen? So zeitlich versetzt bspw. um Wartezeiten bei
Job A durch Ranklotzen bei Auftrag B zu kompensieren? ;-))
>> [...] Wenn man dann noch die entsprechenden Tricks kennt, wie bspw.
>> Erhöhung des "/ImageMemory" Wertes auf 75% des dem Distiller zugeteilten RAM
>> (in den joboptions einzustellen) [...]
>
> Und wo wird das RAM abgezweigt?
Wie meinen? Der /ImageMemory Parameter bestimmt, ab welcher Grösse von
Bildobjekten der Distiller eine temporäre Datei je Bildobjekt anlegt. Ist
der Wert nett niedrig (wie die 5 MByte, die in nahezu allen joboptions
voreingestellt sind) dann kann man dem Distiller ruhig RAM zuweisen bis zum
Abwinken -- es nützt eben meistens herzlich wenig, v.a. wenn man das
klassische MacOS als Distillerplattform einsetzt, da das ein herrlich
lahmes Dateihandling hat. Alleine der Wechsel auf NT oder Abkömmlinge kann
bei ähnlich performanter Hardware schon *richtig* spürbar schneller sein)
> Ich kenne das nur von unserem Viper-RIP, wo es einen Schieberegler gibt,
> den ich von "Vektor Graphics" bis hin zu "Images" schieben kann. Einen
> großen Unterschied macht das allerdings nicht ...
<Sarkasmus> Der Schieberegler wurde wahrscheinlich auf Drängen der
AGFA-Marketingabteilung eingebaut, damit die Kunden ein besseres Feeling
haben. Funktionalität steckt keine dahinter </Sarkasmus>.
Oder andersrum: Es kommt wohl drauf an, was für Arten von Jobs durchgehen.
Jedenfalls ist auf keinen Fall mit einem Viper-RIP (dank UNIX als Plattform)
mit ähnlich dramatischen Auswirkungen wie unter dem klassischen MacOS zu
rechnen.
> Ordnung ist das halbe Leben, zumindest was die Strukturen auf Servern
> anbelangt ;-)
Yo, vor allem wenn mehr als eine Person an einem Job arbeitet und alleine
durch die Ablage am richtigen Ort alle wissen, wie der Status jeder Datei
ist.
> Wobei mir die Datei-Doppelung bei HELIOS auch nicht sonderlich behagt.
Die es abgesehen davon "eigentlich" nicht immer braucht. Man kann auch den
klassischen Weg gehen und einfach Feindaten platzieren und beim Drucken dann
durch "TIFF und EPS auslassen", das Layoutprogramm zwingen, OPI-Kommentare
in den PS-Code einzubetten (leider erzeugen manche Progamme von sich aus
kaputte OPI-Kommentare, so daß die in den Grobbildern durch den Server
eingebauten Äquivalente eindeutig als sicherer zu klassifizieren sind)
Ich nutze das mit den Grobbildern aber schonmal als ersten Preflight für
einkommende Kundendaten. Alles, wovon ich ein Lay bekomme, interessiert mich
nicht mehr (da ich davon ausgehen kann, daß der Server damit umgehen kann
und deshalb auch bei der Ausgabe keine Überraschungen -- bzw. keine von mir
verursachten -- auftreten)
Mir ist es bspw. auch egal, in welchen Farbräumen Bilder angeliefert werden.
Die werden eben erstmal vollautomatisch mit Standardprofilen bei der Ausgabe
separiert und dann ggf. in einem zweiten Schritt auf Kundenwunsch hin
optimiert (aufpreispflichtig natürlich)
> Mir fehlt da immer ein bisschen das Vertrauen in die OPI-Server und die
> entsprechenden Konzepte.
Stimmt schon. Die dahinterstehenden Konzepte bzw. Wirkweisen muß sich
zumindest ein Admin mal zu eigen machen. Es gibt auch ein paar potentielle
Fehlerquellen.
IMO wird man aber dadurch entschädigt, daß der Rest der Belegschaft sich
das Nachdenken ein wenig mehr sparen kann und man einfach insg. deutlich
produktiver zur Sachen gehen kann.
> Wenn ich Bild X in QXP lade, dann will ich auch Bild X im Output haben.
Das hast Du aber in den seltensten Fällen, schon klar, oder? Gerade Xpress
hat auf extremste Weise vorgemacht, wie es sich über alle Einstellungen
hinwegsetzt und Bilder auch bei ausgeschaltetem Downsampling (in Xpress)
trotzdem bis zur Verstümmelung runterrechnet, etc.
*Gerade* deshalb finde ich OPI und Xpress ein so nettes Paar ;-)
> Und spätestens bei der Weitergabe von offenen QXP-Dateien wird's wieder
> schwierig, trotz OPI-Swapper XT und ähnlichen Geschichten.
Apropos "ähnliche Geschichten": XS Picture Manager [LE|Pro] ist definitiv
einen näheren Blick wert (selbst ohne OPI, wenn man nur immer mal wieder
wüst strukturierten Datenmüll vom Kunden angeschwemmt bekommt und die Bilder
neu verknüpfen muß).
Aber insgesamt betrachtet stimmt das natürlich. Wenn man sich selbst auf die
"heilenden" Fähigkeiten des OPI-Servers verläßt und keine Probleme in der
Gestaltungs- und Datenveredelungsphase hat aber dann bspw. offene Dateien
nebst 1-File EPS rausgibt und die irgendwo von Hein Blöd separiert in ein
CtP-System geschoben werden (und alle nur im Schwarzkanal rauskommen) dann
ist das Geschrei oftmals groß. Nur... wo ist denn da der Fehler zu suchen?
Bei Dir, wenn Du fortgeschrittene Produktionsmethoden anwendest oder wenn
bei irgendeinem späteren Partner in der Produktionskette das Fachwissen nur
homöopathisch dosiert den Mitarbeitern verabreicht wurde?
> Aber das ist vermutlich alles eine Frage eines stimmigen Workflow-Konzepts
> und einer gewissen Eingewöhung ;-)
In der Tat.
Gruss,
Thomas
Thomas Kaiser
<news:BA5A07DA.3D245%Thomas...@phg-online.de>:
> Einzig GhostScript 7 ist noch im Rennen. Ich lasse das jetzt noch ein
> Stündchen laufen, dann gucken wir mal...
Bei
/iterate 16 def
wird innerhalb 41 Minuten eine 210 MByte grosse PDF-Datei ausgespuckt (auf
einem 1 GHz PIII, der in der Zeit nichts anderes mehr gemacht hat).
Vielleicht passt sogar der Inhalt des entstandenen PDF (Acrobat kann's
zumindest nicht mehr darstellen wegen Speichermangel :-)
Gruss,
Thomas
Achim Denzl
> [Downsampling und Bilddatenkomprimierung innerhalb PS-Stream]
> > Allerdings setzt das immer einen Server voraus, direkt aus dem
> > Anwendungsprogramm ist das nicht möglich.
>
> Je nach Anwendung. Photoshop bspw. beherrscht es schon länger, Bilder
> komprimiert in PostScript zu verpacken.
Sorry, da hätte ich mich präziser ausdrücken sollen: Ich meinte
natürlich Layout-Programme wie QXP oder FreeHand.
> > Wir haben die ps-Dateien dann vor dem Versand gestufft, das sparte nochmal
> > mindestens die Hälfte an Platz.
>
> Das hässliche an externer Komprimierung ist aber, daß die gepackten Dateien
> am Ziel wieder entpackt werden müssen. Bei Helios bspw. gibt es die
> Möglichkeit, externe Komprimierung on-the-fly einzusetzen schon länger (5-6
> Jahre IIRC). Dabei wird der Ausgabedatenstrom eben direkt per LZW oder ZIP
> gepackt. Blöder Nebeneffekt: das dicke PostScript-File von bspw. 1,9 GByte
> Grösse bereitet vielen Ausgabebetrieben massive Probleme, da es entpackt
> mehr als 2 GByte hätte und damit an diverse Dateisystemlimitationen stösst.
Dank PDF gibt's dieses Problem ja praktisch nicht mehr ;-)
> > Eine interne JPEG-Kompression wäre da allerdings effektiver, zugegeben ...
>
> Je nachdem (es gibt die motivabhängigen Spezialfälle, bei denen LZW- oder
> ZIP-Kompression effektiver ist als DCT). Aber auch wenn es um verlustfreie
> Kompression geht, ist die "interne" Komprimierung von Bilddaten IMO besser
> (zumindest wenn das Ziel-RIP PostScript Level 2 und damit die nötigen InRIP
> Dekodierungsroutinen beherrscht)
Ah ja, gutes Thema. Da fällt mir gleich noch eine Frage ein, die mich
schon seit längerer Zeit interessiert (ich könnte es zwar einfach
ausprobieren, aber trotzdem ;-)
Wenn ich ein LZW-komprimiertes TIFF-Bild in QXP platziere und das auf
einem Level 2 / PS 3-Geräte ausgebe, werden dann die Bilddaten im
Postscript-Stream komprimiert übertragen und erst im RIP entpackt oder
löst Quark schon vorher die LZW-Kompression auf und schickt Rohdaten zum
RIP? Wie ist das beim Distiller, was läuft "besser", mit oder ohne LZW?
> [Wechsel von separiertem Workflow auf Composite]
> > Falls du damit auf die fehlenden Überfüllungsdaten in Quark-Compsites
> > anspielst, so ist das natürlich ein Problem.
>
> Das ist nur die Spitze des Eisberges. Ebenso die Probleme, die daraus
> resultieren, daß Xpress mit PostScript Level 1 Methoden die onHost
> Separation von EPS-Dateien probiert (und dabei regelmässig bei
> JPEG-komprimierten EPS auf die Nase fällt). Oder Probleme mit Sonderfarben,
> etc. etc.
Das ist ja eher umgekehrt. Mit dem Compsite-Workflow taucht das
JPEG-EPS-Problem nicht mehr auf, da die Separation im RIP erfolgt
(entsprechend modernes RIP mal vorausgesetzt).
> > Kann Dein hochgelobter H****S-Server eigentlich auch separierte PS- oder
> > PDF-Files zu Composite zusammensetzen?
>
> PDF schon.
Macht er das auch ordentlich? Ich habe die Funktion mal mit dem Apogee
Create Normalizer getestet, der das auch kann. Allerdings kannst Du Dir
das fertige Composite-PDF nicht mehr richtig am Bildschirm anschauen ;-(
> > Nur mal so interessehalber, bevor ich der Promo GmbH auf den Wecker
> > falle: Für die kleinste (Nutzerzahl) HELIOS-Lösung, bestehend aus
> > EtherShare, EtherShare OPI und PDF-Handshake, welche ungefähre Summe
> > sollte man da einplanen?
> > ( ) 1500 Euro
> > ( ) 3000 Euro
> > ( ) 5000 Euro
> > ( ) 7500 Euro
>
> [ ] Keine Ahnung (und Leitung inzwischen dicht, weil sich per wget ein paar
> ISO-Images auf den Server quälen). Aber unter http://www.helios.de bist Du
> nur wenige Klicks von einer Preisliste entfernt.
Ja, hab's gefunden *schluck*
> [OPI-Server einsetzen?]
[...]
> Eindruck, daß die klassischen Mediendienstleister sich zunehmend dagegen
> wehren müssen, zwischen Agenturen und Druckereien, die beide immer weiter
> vom Tätigkeitsfeld her in deren Bereich vorstossen, zermahlen zu werden.
>
> Ich kenne eigentlich nur ganz wenige Betriebe überhaupt im grafischen
> Gewerbe, die es geschafft haben, in den letzten drei Jahren ein nahezu
> unverändertes Leistungsportfolio beizubehalten.
Das ist leider wahr ;-(
> > Die Rechnung lautet also: Wieviel an (Lohn-) Kosten kann ich durch
> > Einsatz eines entsprechenden Servers einsparen, und in welchem Zeitraum
> > amortisiert sich auf dieser Grundlage die Anschaffung.
>
> Oder was kann ich noch alles damit anstellen; in welchen Bereichen kann ich
> mich zusätzlich von anderen abheben?
>
> Aber an genau der Stelle müssen v.a. auch die Menschen im Vordergrund
> stehen: kann man mit einer technischen Lösung überhaupt den Mitarbeiterstamm
> versorgen, der evtl. andere Arbeitsweisen gewöhnt ist und eine Vereinfachung
> der ihn umgebenden Abläufe als Einschränkung wahrnimmt (mit den üblichen
> Folgen schlechteres Arbeitsklima, Sinken der Produktivität, etc.)
Da bin ich Deiner Meinung. Einen OPI-Server zu benutzen ist IMHO nicht
schwer, ihn (und die technischen Hintergründe) zu begreifen schon eher.
> > Bei unseren größeren Produktionen (die prinzipiell am ehesten davon
> > profitieren könnten), sehe ich keinen großen Nutzen, da unsere Techniker
> > so gut wie nie auf die Technik, aber häufig auf Input vom Kunden warten
> > müssen.
>
> Das klingt ziemlich paradiesisch bzw. danach, daß Ihr weder einen separate
> Dateneingangsabteilung habt (IMO eh nur in Rieseninstallation annähernd
> sinnvoll) oder aber durch Entzerrung von eigentlich aufeinanderfolgenden
> Abläufen (ich wiederhole mich, ich weiß) durch OPI viel verschenkt ;-)
>
> Soll ich eigentlich mal diesbzgl. ein Beispiel posten, damit ein wenig
> klarer wird, von was ich da immer fabuliere?
Ja, mach' doch mal ...
> > Und dann würde eine Investition in schnellere Technologie nur dazu führen,
> > dass die Leerlaufzeiten zunehmen, ohne am gesamten Zeitaufwand etwas zu
> > ändern.
>
> Und wenn Du den Leuten das Vertrauen schenkst, daß sie mehr als einen
> Auftrag pro Tag machen dürfen? So zeitlich versetzt bspw. um Wartezeiten bei
> Job A durch Ranklotzen bei Auftrag B zu kompensieren? ;-))
Auf die Idee bin ich noch gar nicht gekommen ;-)
Bei uns funktioniert das allerdings nicht, da wir unsere Mitarbeiter
_projekt_bezogen einsetzen. Wir sind ja auch nur vier Leute, und zwei
davon kümmern sich ausschließlich um eine größere, wöchentlich
erscheinende Publikation. Der Rest (inklusive mir) bedient die
restlichen Kunden und den Akzidenz-Bereich. Deshalb würde eben auch ein
besseres Serverkonzept keine wirklichen Einsparungen (außer mehr
bezahlte Freizeit für die Mitarbeiter ;-) bringen.
> >> [...] Wenn man dann noch die entsprechenden Tricks kennt, wie bspw.
> >> Erhöhung des "/ImageMemory" Wertes auf 75% des dem Distiller
> >> zugeteilten RAM (in den joboptions einzustellen) [...]
> >
> > Und wo wird das RAM abgezweigt?
>
> Wie meinen? Der /ImageMemory Parameter bestimmt, ab welcher Grösse von
> Bildobjekten der Distiller eine temporäre Datei je Bildobjekt anlegt. Ist
> der Wert nett niedrig (wie die 5 MByte, die in nahezu allen joboptions
> voreingestellt sind) dann kann man dem Distiller ruhig RAM zuweisen bis zum
> Abwinken -- es nützt eben meistens herzlich wenig, v.a. wenn man das
> klassische MacOS als Distillerplattform einsetzt, da das ein herrlich
> lahmes Dateihandling hat. Alleine der Wechsel auf NT oder Abkömmlinge kann
> bei ähnlich performanter Hardware schon *richtig* spürbar schneller sein)
Ah, verstehe. Ich hab's heute mal entsprechend eingestellt, und rein
subjektiv schien das schon einiges zu bringen. Im Lauf der Woche werde
ich's mal objektiv testen. Der wird ist wohl in Byte angegeben? Das
würde bedeuten, dass der Distiller in der Grundeinstellung alle Bilder >
500 kB auf die Platte swappt? Ziemlich unsinnig, in der Tat ;-/
> > Ich kenne das nur von unserem Viper-RIP, wo es einen Schieberegler gibt,
> > den ich von "Vektor Graphics" bis hin zu "Images" schieben kann. Einen
> > großen Unterschied macht das allerdings nicht ...
>
> <Sarkasmus> Der Schieberegler wurde wahrscheinlich auf Drängen der
> AGFA-Marketingabteilung eingebaut, damit die Kunden ein besseres Feeling
> haben. Funktionalität steckt keine dahinter </Sarkasmus>.
Nö, mir würde jetzt auch nichts einfallen, was man mit diesem Regler
sinnvoll verändern können sollte ...
> Oder andersrum: Es kommt wohl drauf an, was für Arten von Jobs durchgehen.
> Jedenfalls ist auf keinen Fall mit einem Viper-RIP (dank UNIX als Plattform)
> mit ähnlich dramatischen Auswirkungen wie unter dem klassischen MacOS zu
> rechnen.
Da stimmt jetzt aber was nicht:
AGFA VIPER = Mac (Classic)
AGFA TAIPAN = WIN (oder UNIX, glaub' ich)
> > Ordnung ist das halbe Leben, zumindest was die Strukturen auf Servern
> > anbelangt ;-)
>
> Yo, vor allem wenn mehr als eine Person an einem Job arbeitet und alleine
> durch die Ablage am richtigen Ort alle wissen, wie der Status jeder Datei
> ist.
Eben ;-)
In solchen Szenarien lassen sich übrigens auch die "Etiketten"
hervorragend einsetzen. Bei uns werden zum Beispiel Bilder zwar von
Anfang an korrekt in Hinblick auf Größe und Auflösung gespeichert, die
eigentliche Bildbearbeitung erfolgt aber oft erst später, nach dem
Layouten beispielsweise. Die endfertigen Bilder kriegen ein grünes
Etikett, und man sieht auf einen Blick, wo man noch anpacken muss.
> > Wobei mir die Datei-Doppelung bei HELIOS auch nicht sonderlich behagt.
>
> Die es abgesehen davon "eigentlich" nicht immer braucht. Man kann auch den
> klassischen Weg gehen und einfach Feindaten platzieren und beim Drucken dann
> durch "TIFF und EPS auslassen", das Layoutprogramm zwingen, OPI-Kommentare
> in den PS-Code einzubetten (leider erzeugen manche Progamme von sich aus
> kaputte OPI-Kommentare, so daß die in den Grobbildern durch den Server
> eingebauten Äquivalente eindeutig als sicherer zu klassifizieren sind)
>
> Ich nutze das mit den Grobbildern aber schonmal als ersten Preflight für
> einkommende Kundendaten. Alles, wovon ich ein Lay bekomme, interessiert mich
> nicht mehr (da ich davon ausgehen kann, daß der Server damit umgehen kann
> und deshalb auch bei der Ausgabe keine Überraschungen -- bzw. keine von mir
> verursachten -- auftreten)
Das meinte ich eben: Da wurschtelt ein Maschinchen im Hintergrund an den
Dateien rum, ohne dass man ihm das explizit sagen muss. Das widerspricht
(zumindest für mein Empfinden) der Definition eines FileServers:
Dateien, die ich da drauf packe, will ich auch genauso wiederhaben ;-)
> > Wenn ich Bild X in QXP lade, dann will ich auch Bild X im Output haben.
>
> Das hast Du aber in den seltensten Fällen, schon klar, oder? Gerade Xpress
> hat auf extremste Weise vorgemacht, wie es sich über alle Einstellungen
> hinwegsetzt und Bilder auch bei ausgeschaltetem Downsampling (in Xpress)
> trotzdem bis zur Verstümmelung runterrechnet, etc.
Wenn man die Bilder vorher _ordentlich_ bearbeitet, dann wird von Quark
da nichts downgesamplet. AFAIK rechnet Quark erst bei mehr als doppelt
zu hoher Bild-Auflösung auf den korrekten Wert von 2 x Rasterweite
runter. Und im 4er Quark kann man das abschalten; IMHO sowieso sinnvoll,
da der Distiller das bestimmt besser kann ;-)
> *Gerade* deshalb finde ich OPI und Xpress ein so nettes Paar ;-)
Stimmt, die HELIOS PublicBeta und QXP haben sich ziemlich gut vertragen.
> Aber insgesamt betrachtet stimmt das natürlich. Wenn man sich selbst auf die
> "heilenden" Fähigkeiten des OPI-Servers verläßt und keine Probleme in der
> Gestaltungs- und Datenveredelungsphase hat aber dann bspw. offene Dateien
> nebst 1-File EPS rausgibt und die irgendwo von Hein Blöd separiert in ein
> CtP-System geschoben werden (und alle nur im Schwarzkanal rauskommen) dann
> ist das Geschrei oftmals groß. Nur... wo ist denn da der Fehler zu suchen?
> Bei Dir, wenn Du fortgeschrittene Produktionsmethoden anwendest oder wenn
> bei irgendeinem späteren Partner in der Produktionskette das Fachwissen nur
> homöopathisch dosiert den Mitarbeitern verabreicht wurde?
Ich glaube, der Mittelweg zwischen etablierter, aber u. U. veralteter
Technik und modernen, aber nicht durchgängig verfügbaren Methoden ist
wohl der Richtige. Auch wenn PS 3 sicher gewisse Vorteile hat, ist wohl
nach wie vor PS Level 2 als "Standard" anzusehen; insbesondere, weil man
eigentlich ruhigen Gewissens davon ausgehen kann, dass dieses Format
jeder verarbeiten kann. Und bei PDF ist es ähnlich, es vergehen einfach
immer ein paar Jahre, bis eine neue, moderne Technik sich in allen
Bereichen durchgesetzt hat. Womit wir wieder OT wären *freu*
Achim Denzl
> > Ansonsten sind natürlich sachdienliche Hinweise herzlich willkommen,
>
> Siehe bspw. <news:3B0559...@srz-berlin.de>. Allerdings solltest Du die
> epilogue.ps in Betracht ziehen, da das graphische Modell von PostScript
> davon ausgeht, daß Seitenelemente, die zuerst gezeichnet werden unter den
> nachfolgenden liegen. Die prologue.ps eignet sich also eher für
> Wasserzeichen und Sachen, die hinter den aktuellen Seiten liegen.
Der genannte Link sieht schon mal vielversprechend aus. Ich hab das zwar
aus Zeitgründen noch nicht testen können, aber aber das nächste freie
Wochenende kommt bestimmt (hoffentlich?) ...
Erstmal Danke für die Hilfe!
Thomas Kaiser
<news:BA5B72FE.3AB3A%tsch...@gmx.net>:
> Habt ihr vielleicht einen Tip, wo QXP und PDF kompetent diskutiert wird?
Probier es mal hier:
<http://pdfzone.hightext.de/forum/>
Das ist die inzwischen dritte Auflage einer ursprünglich recht chaotischen
Mailingliste, die das pdfzone.de Projekt von Thomas Müller (tingelt mit
Acrobat Schulungen durch die Lande und hat früher mal ein mittelprächtiges
PDF-Buch geschrieben <http://www.pdfzone.de/pub/Buch/acrobuch.pdf>) und die
Redaktion der Publishing Praxis auf die Beine gestellt haben.
Mittlerererweile tummelt sich dort eigentlich alles, was Rang und Namen hat
und es lohnt sich die Beiträge lokal zu archivieren. Ebenfalls interessant
sind die Listen der ECI (<http://www.eci.org/deu/index_d.html>), die
ebenfalls wahnsinnig viel Kompetenz bündeln:
<http://lists.transmedia.de/mailman/listinfo/eci>
<http://lists.transmedia.de/mailman/listinfo/pdfx3>
Gruss,
Thomas
Thomas Kaiser
> Kurze Frage, ist der JAWS-PDF-Server für ernsthafte Publishing Aufgaben
> brauchbar,
IMO ja. Das zugrundeliegende RIP bzw. der PostScript Interpreter waren auch
früher schon in der Druckvorstufe in einigen Produkten zu finden (bspw. bei
BARCO, PVD, etc.). Auch wenn Harlequin früher mit dem Argument der
Geschwindigkeit gegenüber anderen Interpretern angetreten ist, war aus
eigener Erfahrung (Xeikon DCP/50 mit sowohl Harlquin Scriptworks als auch
BARCO FastRIP) der JAWS-Interpreter deutlich schneller. JAWS für die
Geschwindigkeit und wenn dann mal ein Job nicht lief, dann eben auf
Scriptworks umsatteln, da man das -- entsprechend parametrisiert --
normalerweise dazu bringen kann, nahezu alles zu fressen.
> oder ist das eher ein Office-Produkt a la Feld-Wald-und-Wiesen-PDF von
> jedem Arbeitsplatz aus?
So wird es heute primär positioniert, da Global Graphics vielleicht sogar
noch vor Adobe selbst erkannt hat, daß in dem Segment der Rubel schneller
rollt als bei den paar Publishing Heinis ;-)
Bzgl. der Praxistauglichkeit muß man sich natürlich exakt die
Einschränkungen anschauen, die der JAWS-Lösung innewohnen und im Hinterkopf
haben, daß der Distiller als quasi-Industriestandard anzusehen ist, der
einfach die Referenz darstellt (samt seiner Fehler).
Da ich den JAWS PDF-Server selbst aber noch nie ausprobiert habe (nur durch
Anwenderberichten und Testartikel damit in Berührung gekommen), ist das mit
Vorsicht zu geniessen, was ich hier schreibe.
Sinnvoller ist es wohl in einem entsprechenden Forum nachzufragen. Siehe
auch <news:BA5BEBFB.3D496%Thomas...@phg-online.de>
Gruss,
Thomas
Thomas Kaiser
<news:1fpgslw.1w4vs4ygnvipsN%use...@dtpd.com>:
> Wenn ich ein LZW-komprimiertes TIFF-Bild in QXP platziere und das auf
> einem Level 2 / PS 3-Geräte ausgebe, werden dann die Bilddaten im
> Postscript-Stream komprimiert übertragen
Zumindest bis einschließlich Xpress 4.1 nicht.
> und erst im RIP entpackt
Das geht nur, wenn die Daten vorher in einem EPS steckten. Mit LinoColor
bspw. hatte man die Möglichkeit 1 Bit Strichabbildungen als EPS mit
ursprünglich LZW und später der effizienteren CCITT Group 4 Kompression zu
speichern. Das war ein richtiger Traum, da Xpress zum einen elend lahm ist
beim Importieren von komprimierten TIFFs und zum anderen Deine folgende
Frage mit ja beantwortet werden muß.
> löst Quark schon vorher die LZW-Kompression auf und schickt Rohdaten zum
> RIP?
Nicht unbedingt "roh" aber zumindest unkomprimiert ;-)
> Wie ist das beim Distiller, was läuft "besser", mit oder ohne LZW?
Wie meinst Du? Der kriegt von Xpress ja sowieso unkomprimierte Bit- und
Bytemaps vorgeworfen...
[Xpress scheitert an Separation von JPEG-komprimierten CMYK-EPS]
> Das ist ja eher umgekehrt. Mit dem Compsite-Workflow taucht das
> JPEG-EPS-Problem nicht mehr auf, da die Separation im RIP erfolgt
> (entsprechend modernes RIP mal vorausgesetzt).
Ja, stimmt. Da hatte ich mich schon in Rage geschrieben ;-)
>>> Kann Dein hochgelobter H****S-Server eigentlich auch separierte PS- oder
>>> PDF-Files zu Composite zusammensetzen?
>>
>> PDF schon.
>
> Macht er das auch ordentlich?
Für die Ausgabe schon und nur da funktioniert das auch. Ist also kein
generisches "Zusammenfügen"-Werkzeug wie bspw. Seps2Comp (das IMO weiterhin
unverzichtbar bleibt für manche Aufgabenstellungen)
> Ich habe die Funktion mal mit dem Apogee Create Normalizer getestet, der
> das auch kann.
Der schichtet einfach die 4 Layer überdruckend übereinander.
> Allerdings kannst Du Dir das fertige Composite-PDF nicht mehr richtig am
> Bildschirm anschauen ;-(
Da hätte AGFA einfach noch eine composite Preview rechnen müssen und die
dann drüber kleben müssen in einem nicht druckenden Formularfeld oder sowas.
[Vorteile eines OPI-Workflow]
>> Soll ich eigentlich mal diesbzgl. ein Beispiel posten, damit ein wenig
>> klarer wird, von was ich da immer fabuliere?
>
> Ja, mach' doch mal ...
Na gut. Es war einmal in einer kleinen Klitsche, in der ich vor ein paar
Jahren arbeitete... *ggg*
Auftragsstruktur zu gleichen Dritteln Reproduktion von hochwertigen Koch-
und Reisebüchern, Magazinproduktion (inkl. Anzeigenabwicklung) und
Datenklempnerei bzw. eben CtF-Dienstleister, der aus offenen Dateien fertige
Filmbögen im 70x100 Format abgeliefert hat (moderne Alchemie, wie der Chef
zu sagen pflegte: "Aus Sch***e Gold machen")
Ich war dort eigentlich Mädchen für alles jenseits der Hilfstätigkeiten,
bzw. habe mir immer schön die mir genehmen Stücke aus dem Auftragskuchen
rausgeschnitten, bis ich wegen Überlastung eines Kollegen eines seiner
Magazine aufs Auge gedrückt bekam. Er wünschte mir nur viel Spaß und
prophezeite mir, daß ich binnen kürzester Zeit in der Klapse landen würde,
womit er wohl recht behalten hätte, wenn ich nicht die Arbeitsbedingungen so
geändert hätte, daß ich das Magazin nebenher abwickeln konnte (gibt ja noch
wichtigeres als Arbeit ;-)
Resultierende Auftragsstruktur war folgende:
Feinbilder ok
layouts
Rohscans %0
Kundendaten
23.1.2003
24.1.2003
Umbruch-RZ
In "Feinbilder ok" durften per Definition nur auskorrigierte und
kundentaugliche Bilddaten, die inhouse produziert wurden, liegen (und
natürlich die Grobbilder im Unterordner "layouts"). In "Rohscans %0"
kamen die originalen Scans von den Flachbett- oder vom Trommelscanner. In
Kundendaten wurde je Anlieferung ein Unterordner erzeugt und alles, was eben
per ISDN, Catridge, CD daherkam reingeworfen. Und in "Umbruch-RZ" lagen
schließlich die von mir benutzten Xpress-Dateien, benannt nach einer simplen
Konvention (Auftragsnummer_Seitenzahl_Beschreibung)
Das Problem war, daß das Magazin wegen max. 1 Arbeitstag Durchlaufzeit
zwischen Vorlagenablieferung und Proofauslieferung eher "Schnellschuß"
Charakter hatte. Die Vorlagen kamen am 1. Tag gegen 18:00 Uhr an und sollten
zwei Tage darauf in aller Frühe wieder beim Kunden sein, d.h. de Facto
musste immer alles innerhalb des dazwischen liegenden Arbeitstages
geschehen. Meistens war es aber ein Riesen-Heckmeck mit gelieferten
Anzeigen-EPS, fehlenden Schriften seitens der Graphiker, falsch gelieferten
Bildern, etc.
Ich hatte nun das Glück, daß eine Kollegin aus der Scan-/Retusche-Abteilung
gerne spät und eine andere gerne früh arbeitete. So hat mir dann die erste
in aller Ruhe die abends angelieferten Vorlagen aufgespannt und in die Nacht
hinein in den "Rohscans %0" Ordner scannen lassen. Ein Skript von mir hat
dann auf dem Server diese Rohscans in aller Frühe in den "Feinbilder ok"
Ordner kopiert, dort ein Grobbild erzeugt und das eigentliche Feinbild in
diesem Ordner wieder gelöscht (denn die Rohscans waren ja noch nicht
auskorrigiert und daher nicht prooftauglich)
Das bedeutete, daß ich mir dann am nächsten morgen die Xpress-Dateien in
den "Kundendaten", die frisch gekommen waren, vornahm und nun einfach die
Grobbilder aus "Feinbilder ok:layouts" einbauen konnte und parallel gucken
konnte, was alles an den angelieferten Kundendaten nicht in Ordnung war
(fehlende oder defekte Bilder und/oder Schriften). Das Kontrollkriterium für
angelieferte Kundenbilder war wirklich einfach: Hat der Server ein Lay
gemacht, war alles i.O.; wenn nicht, musste ich das Bild prüfen und ggf. neu
anfordern. D.h. nach einer halben Stunde wusste ich meistens bereits, was
ich alles vom Verlag nachordnern musste. Gegen Mittag war das Zeugs dann
meistens da und ich machte die restlichen Seiten startklar, indem ich sie in
eine "Print-to-Disk" Queue auf dem Server schickte, der Jobs als
PostScript-Dateien mit inkludierten Grobbildern in einem Verzeichnis ablegte
und parallel auf ein RIP ballerte (immer noch mit Grobbildern der eigenen
Scans aber schon mit Feinbildern der vom Verlag gelieferten Bilder und v.a.
Anzeigen-EPS). Dieses RIP erzeugte TIFFs, die automatisch nach 24 Stunden
gelöscht wurden. Bereitete jetzt eine Seite Probleme, so landete die Seite
in der Fehlerqueue und ich konnte dem Problem en Detail nachgehen, den Täter
identifizieren und ggf. eine Anzeige von Hand reparieren oder erneut als EPS
anfordern oder wenigstens die darin verwendeten Schriften (und was halt noch
so alles gerne schief gehen kann).
Zu diesem Zeitpunkt waren aber die eigenen Scans immer noch unkorrigiert,
ich jedoch schon nahezu komplett fertig mit den PS-Dateien, die für's Proof
bzw. ebenfalls für die endgültige Auslieferung an die Druckerei bestimmt
waren *und* hatte bereits jetzt die Gewißheit, daß die Seiten keine
PostScript-Fehler mehr erzeugen und keine fehlenden Bilder oder Schriften
zum "show stopper" werden konnten. Am Nachmittag/frühen Abend wurden dann
die Rohscans geöffnet, auskorrigiert (die üblichen Sonderwünsche automatisch
berücksichtigt, die man mit der Zeit je Kunde automatisch adaptiert) und in
"Feinbilder ok" gespeichert. Bevor die Kollegin dann am Abend heimging, hat
sie einfach die PS-Dateien über eine andere Queue (die für alle Grobdaten
das Replacement gegen Feindaten machen sollte und daher auf fehlende
Feinbilder prüft und im Bedarfsfall wiederum den Job in eine andere
Fehlerqueue verschoben hat) auf das Proof geschoben, das dann über Nacht die
Seiten (als Doppelseiten mit eingestreuten Schneidzeichen) ausgegeben hat.
Gesetzt den Fall, ein Bild war noch nicht auskorrigiert (also nicht in
"Feinbilder ok" enthalten), so ist der entsprechende Proofbogen in der
Fehlerqueue gelandet. Diese wurde in der Früh von der Kollegin aus der
Frühschicht geöffnet, der Job doppelgeklickt, abgelesen, welches Bild fehlt,
dieses schnell auskorrigiert und dann der Job einfach per Drag&Drop aus der
Fehlerqueue auf die Prooferqueue geschoben.
Ich konnte dann in der früh in 99% der Fälle sofort einen Blick auf die
Proofs werfen und dann parallel mit den inzwischen wieder abmontierten und
geputzten Vorlagen retour an den Verlag schicken.
Sollten an Seiten nur Bildkorrekturen anfallen, so wurden die in der
Retuscheabteilung gemacht; in diesen Fällen musste ich die Xpress-Seite
nicht mehr anfassen, da ja sonst nichts Inhaltliches an der Seite geschehen
ist. Es reichte völlig, die PS-Datei erneut über die OPI-Queue auf den
Proofer zu schieben :-)
Wurde die Seite dann freigegeben, so habe ich einfach die ursprünglich
erzeugten LowRes PS-Dateien per DropPS erneut über eine OPI-Queue geschoben
und hinten ist ein HighRes PS-File, fix und fertig für die Druckerei,
rausgefallen.
Knapp 80% der Xpress-Seiten habe ich überhaupt nur einmal geöffnet, da das
PS-File, das ich im ersten Schritt erzeugt hatte, bereits die richtigen
Feinbild-Referenzierungen enthielt und daher nicht wieder angefasst werden
musste, außer es traten natürlich Text- oder Positionierungskorrekturen auf.
Ich konnte das Proof beruhigt in der Nacht laufen lassen, weil ich mittags
dasselbe RIP schon ein TIFF der Seite habe rechnen lassen (also keine
Überraschungen durch PS-Fehler mehr möglich) und die Überprüfung auf nicht
oder falsch gelieferte Daten seitens Verlag konnte ich auch völlig
unabhängig von dem Korrekturstatus der Bilder angehen (was sich ja
normalerweise nicht lohnt, da man ansonsten die Seiten zweimal öffnen
müsste).
Dieses Magazin auf die Art zu produzieren war quasi ein netter Spaziergang
nebenher, der mich 7-8 Tage je Monat pro Tag max. 1 Std. Arbeit gekostet hat
(na gut, ich hatte natürlich auch AppleScripts, die sich zum Teil um
Bildverknüpfungen, das Einrichten des Drucksetups und das Einzelseiten-weise
Losschicken der Seiten gekümmert haben). Aber grundsätzlich ließ sich eben
durch die Entzerrung normalerweise aufeinanderfolgender Produktionsschritte
massiv Zeit sparen, sehr frühzeitig auf Fehler(quellen) reagieren und
letzten Endes durch den OPI-Mechanismus die Produktionssicherheit drastisch
erhöhen.
Ich wollte die Mechanismen damals noch weiter aufbohren, habe aber dann den
Laden gewechselt (Cheffe hat mir vorgerechnet, daß durch die neue optimierte
Arbeitsweise bei der Produktion des Magazins nur noch 55% der Kosten im
Vergleich zu davor entstehen würden. Ich wollte das durch eine angenemessene
Lohnerhöhung ein wenig relativieren, aber er hörte plötzlich ganz schlecht)
Ulkigerweise bin ich dann zu einer anderen Repro, die zwei andere Magazine
für denselben Verlag machten. Dort durfte ich dann sehen, wie man OPI auch
falsch adaptieren kann. Der Knecht, der dort ca. 2 Wochen im Monat am Rande
des Nervenzusammenbruchs die Magazine durch die Produktion drückte, benutzte
OPI nur, indem er beim Drucken "TIFF&EPS auslassen" im Druckdialog anwählte
(die ließen keine Grobdaten auf dem Server automatisch erzeugen).
Naja, dort wurde dann in der Folgezeit einiges umgestellt, als sie endlich
mal kapiert hatten, was man mit OPI noch anfangen kann als nur 10 Minuten
pro Monat je Mitarbeiter durch schnelleres Spoolen zu sparen :-)
>> Jedenfalls ist auf keinen Fall mit einem Viper-RIP (dank UNIX als Plattform)
>> mit ähnlich dramatischen Auswirkungen wie unter dem klassischen MacOS zu
>> rechnen.
>
> Da stimmt jetzt aber was nicht:
> AGFA VIPER = Mac (Classic)
Argh. Ich hatte das mit Cobra verwechselt -- das lief unter Solaris.
> AGFA TAIPAN = WIN (oder UNIX, glaub' ich)
Taipan ist das NT-RIP, genau. Oh Mann, AGFA und die Namen :-(
[Automatische Grobbild-Erstellung auf OPI-Server]
> Da wurschtelt ein Maschinchen im Hintergrund an den Dateien rum, ohne
> dass man ihm das explizit sagen muss.
Doch, doch, das sagst Du ihm explizit, indem Du das ganze global
einschaltetst. Auf Ordnerebene hast Du dann noch durch
Ordnernamenkonventionen weitreichende Möglichkeiten, das Verhalten zu
steuern, bspw. indem Du ein "%0" anhängst, was die Grobbilderzeugung für
alle Unterordner stoppt, oder bspw. ein %144g, was dazu führt, daß Du im
layouts Ordner Grobbilder im PNG-Format mit 144 dpi erhältst, etc. (Hint:
Alle, die sich von Photoshop Bilder "fürs Web" runterrechnen lassen sind
irgendwie selbst schuld ;-)
> Das widerspricht (zumindest für mein Empfinden) der Definition eines
> FileServers: Dateien, die ich da drauf packe, will ich auch genauso
> wiederhaben ;-)
Die kriegst Du ja auch so wieder! Brauchst ja bloß die Feindaten einbauen
und fertig. Aber Du kriegst ebenso die Möglichkeit, noch mehr mit den
Bildern zu machen, also bspw. automatisch eine Separation von bspw. Scans im
RGB-Farbraum (mit getaggten Scannerprofilen) für eine Zeitungsrotation
(ICC-Profil der Ausgabewarteschlange zugeordnet) on-the-fly durchführen zu
lassen.
>>> Wenn ich Bild X in QXP lade, dann will ich auch Bild X im Output haben.
>>
>> Das hast Du aber in den seltensten Fällen, schon klar, oder? Gerade Xpress
>> hat auf extremste Weise vorgemacht, wie es sich über alle Einstellungen
>> hinwegsetzt und Bilder auch bei ausgeschaltetem Downsampling (in Xpress)
>> trotzdem bis zur Verstümmelung runterrechnet, etc.
>
> Wenn man die Bilder vorher _ordentlich_ bearbeitet, dann wird von Quark
> da nichts downgesamplet.
Hallo? Ich will meine Bilder nicht vorher prüfen müssen, ob sie den formalen
Kriterien einer amoklaufenden Layoutapplikation entsprechen. Ich will die
einbauen und will, daß anschließend "das Richtige passiert".
> AFAIK rechnet Quark erst bei mehr als doppelt zu hoher Bild-Auflösung auf
> den korrekten Wert von 2 x Rasterweite runter.
Yo. Und das manchmal auch bei Strich-TIFFs. Da kommt Laune auf :-)
> Und im 4er Quark kann man das abschalten;
Nein. Siehe Samuel Hüglis Pflichtlektüre "Insiderbuch Quark Xpress" (Mist,
grad festgestellt, daß beide Exemplare verliehen habe). Xpress hält sich
nicht immer an das Verbot des Runterrechnens. BTW: Unter Xpress 3.3 konnte
man den selben Effekt auch durch Einsatz der kostenlosen "PS Utilities 1.2"
XTension erreichen, die netterweise sogar richtig funktionierte.
>> Aber insgesamt betrachtet stimmt das natürlich. Wenn man sich selbst auf die
>> "heilenden" Fähigkeiten des OPI-Servers verläßt und keine Probleme in der
>> Gestaltungs- und Datenveredelungsphase hat aber dann bspw. offene Dateien
>> nebst 1-File EPS rausgibt und die irgendwo von Hein Blöd separiert in ein
>> CtP-System geschoben werden (und alle nur im Schwarzkanal rauskommen) dann
>> ist das Geschrei oftmals groß. Nur... wo ist denn da der Fehler zu suchen?
>> Bei Dir, wenn Du fortgeschrittene Produktionsmethoden anwendest oder wenn
>> bei irgendeinem späteren Partner in der Produktionskette das Fachwissen nur
>> homöopathisch dosiert den Mitarbeitern verabreicht wurde?
>
> Ich glaube, der Mittelweg zwischen etablierter, aber u. U. veralteter
> Technik und modernen, aber nicht durchgängig verfügbaren Methoden ist
> wohl der Richtige.
IMO gibt es keinen Mittelweg. Die Anforderungen sind ziemlich klar, wenn man
sich auf das Abenteuer composite Workflow einstellt. Will man den Weg gehen,
braucht man neue Werkzeuge, neues und umfassendes Wissen und den Willen,
sich täglich mit neuen Problemen auseinanderzusetzen. Spätestens an der
Stelle fange ich dann aber immer an, mir Gedanken zu machen, wie ich
vermeiden kann, daß man jede Woche wieder in die selben Fallen tappt. Und da
bietet sich eben der Einsatz von Automatismen in Form von mitdenkenden
Servern an (sei es ein Print- oder ein OPI- oder ein PitStop-Server, etc.)
> Auch wenn PS 3 sicher gewisse Vorteile hat,
Es ist schlichtweg Grundvoraussetzung, wenn Smooth Shades, CID-Fonts oder
auch Sonderfarben in composite Workflows ins Spiel kommen.
> ist wohl nach wie vor PS Level 2 als "Standard" anzusehen;
Wer mit Xpress arbeitet (arbeiten muß) sollte hier einfach durch PS Level 1
ersetzen. Kommt eher hin :-(
> insbesondere, weil man eigentlich ruhigen Gewissens davon ausgehen kann,
> dass dieses Format jeder verarbeiten kann.
Es kann aber nicht mehr alles transportieren, was heute von Software
eingesetzt wird. Wenn man in InDesign vernünftig mit den Fähigkeiten des
Programms umgeht, dann kommt man an PS 3 nicht herum.
> Und bei PDF ist es ähnlich, es vergehen einfach immer ein paar Jahre, bis
> eine neue, moderne Technik sich in allen Bereichen durchgesetzt hat.
Aber daß die Leute heute in den Druckereien immer noch wegen den selben
Fehlern auf die Fresse fallen, wie zu den Zeiten, als ich dieses Gewerbe
enterte, stimmt mich schon bedenklich. Ist eben Zeit, sich über (mangelndes)
Wissen Gedanken zu machen und gleichzeitig über Mittel und Wege, die
Produktionssicherheit zu erhöhen.
> Womit wir wieder OT wären *freu*
Absolut OT, soz. ;-)
Und aufgrund des Mammut-Posting gleich die Ankündigung, mich eine Woche
dezent zurückzuhalten (Quantitätskompensation :-)
Gruss,
Thomas
Georg Lutz
ich habe Deine Ausführungen mit grossem Interesse gelesen.
Ist ja klasse was Du alles kannst und weisst!
Wieviel verdient eine Person wie Du bei solch einem Job?
Sundenlohn/Monatslohn?
Gibst Du Seminare?
Consulting?
Gruß
von Georg
Thomas Kaiser
<news:georg-503650....@mail.snafu.de>:
> klasse was Du alles kannst und weisst!
Naja, alles nur relativ. Wichtig ist halt, daß man nicht mehr als die Hälfte
der Zeit im Tagesgeschäft steckt, da man sich ansonsten die Chance nimmt,
sich am eigenen Kragen aus dem Sumpf monotoner Tätigkeiten zu ziehen.
Bzw. andersrum: Wenn ich die Hälfte des Tages für "Research&Development"
aufwenden wollte, musste ich bisher immer in der restlichen Hälfte mehr als
doppelt so produktiv sein wie andere Kollegen :-)
> Gibst Du Seminare?
> Consulting?
Auch, ja. Neben (vorwiegend remote) Server- und Systemadministration,
Workflow-Analysen und -Optimierungen und "klassischem" Projektgeschäft.
Aber jetzt wird's endgültig OT. Die eMail-Adresse unter der ich poste, wird
AFAIK korrekt weitergeleitet auf meinen Account --> eMail bei Interesse
ansonsten allgemein hier weiterdiskutieren :-)
Gruss,
Thomas
Achim Denzl
> > Der /ImageMemory Parameter bestimmt, ab welcher Grösse von Bildobjekten
> > der Distiller eine temporäre Datei je Bildobjekt anlegt. Ist der Wert
> > nett niedrig (wie die 5 MByte, die in nahezu allen joboptions
> > voreingestellt sind) dann kann man dem Distiller ruhig RAM zuweisen bis
> > zum Abwinken -- es nützt eben meistens herzlich wenig ...
>
> Ah, verstehe. Ich hab's heute mal entsprechend eingestellt, und rein
> subjektiv schien das schon einiges zu bringen. Im Lauf der Woche werde
> ich's mal objektiv testen.
Heute geschehen, mit verblüffendem Ergebnis!
Testobjekt: Eine "typische" Zeitungsseite mit gemischtem Inhalt (Text,
Bilder, Freisteller, Anzeigen). Größe der PS-Datei: 45 MB.
RIP-Zeit bei unverändertem /ImageMemory-Wert: 283 Sekunden
RIP-Zeit bei /ImageMemory = 20000000: 147 Sekunden
Das enspricht fast einer Verdoppelung der Geschwindigkeit!
Da ich eh gerade am Basteln war, habe ich noch den Einfluß des
"Virtuellen Speichers" auf dem Testrechner geprüft: Nach ersten Tests
scheint es keinen Einfluß zu haben, ob auf dem Distiller-Rechner der
virtuelle Speicher ein- der ausgeschaltet ist.
@Thomas: Danke für den Tipp, hast Dir soeben zur versprochenen Tasse
Kaffee noch eine Mohnschnecke hinzuverdient ;-)
Achim Denzl
> > löst Quark schon vorher die LZW-Kompression auf und schickt Rohdaten zum
> > RIP?
>
> Nicht unbedingt "roh" aber zumindest unkomprimiert ;-)
OK.
> > Wie ist das beim Distiller, was läuft "besser", mit oder ohne LZW?
>
> Wie meinst Du? Der kriegt von Xpress ja sowieso unkomprimierte Bit- und
> Bytemaps vorgeworfen...
Klar, dann ist ja die Frage natürlich obsolet ;-)
[Seps2Comp]
> Da hätte AGFA einfach noch eine composite Preview rechnen müssen und die
> dann drüber kleben müssen in einem nicht druckenden Formularfeld oder sowas.
Die mangelnde Bildschirm-Preview war dann neben dem Preis auch der
Grund, den Distiller zu verwenden, obwohl die Möglichkeit, zunächst
separiert auszugeben und damit auch aus Quark sämtlich Überfüllungen
mitzunehmen in Verbindung mir der PAP-Unterstützung des Normalizers
durchaus verlockend gewesen wäre.
> [Vorteile eines OPI-Workflow]
> >> Soll ich eigentlich mal diesbzgl. ein Beispiel posten, damit ein wenig
> >> klarer wird, von was ich da immer fabuliere?
> >
> > Ja, mach' doch mal ...
>
> Na gut. Es war einmal in einer kleinen Klitsche, in der ich vor ein paar
> Jahren arbeitete... *ggg*
[Nachfolgender Text stark gekürzt]
> Und in "Umbruch-RZ" lagen schließlich die von mir benutzten
> Xpress-Dateien, benannt nach einer simplen Konvention
> (Auftragsnummer_Seitenzahl_Beschreibung)
Wo kamen die denn her? Ich konnte in Deiner Beschreibung überhaupt keine
Zeit für den eigentlichen Satz entdecken?
> Meistens war es aber ein Riesen-Heckmeck mit gelieferten Anzeigen-EPS,
> fehlenden Schriften seitens der Graphiker, falsch gelieferten Bildern,
> etc.
Das kennt man ;-)
> Ich hatte nun das Glück, daß eine Kollegin aus der Scan-/Retusche-Abteilung
> gerne spät und eine andere gerne früh arbeitete. So hat mir dann die erste
> in aller Ruhe die abends angelieferten Vorlagen aufgespannt und in die Nacht
> hinein in den "Rohscans %0" Ordner scannen lassen. Ein Skript von mir hat
> dann auf dem Server diese Rohscans in aller Frühe in den "Feinbilder ok"
> Ordner kopiert, dort ein Grobbild erzeugt und das eigentliche Feinbild in
> diesem Ordner wieder gelöscht (denn die Rohscans waren ja noch nicht
> auskorrigiert und daher nicht prooftauglich)
Und wer hat wann die Freisteller gemacht? Falls es welche gegeben hat,
müssten die ja bereits in diesem Stadium der Produktion fertig gewesen
sein wegen Textumfluß und so ...
> Das bedeutete, daß ich mir dann am nächsten morgen die Xpress-Dateien in
> den "Kundendaten", die frisch gekommen waren, vornahm und nun einfach die
> Grobbilder aus "Feinbilder ok:layouts" einbauen konnte und parallel gucken
> konnte, was alles an den angelieferten Kundendaten nicht in Ordnung war
> (fehlende oder defekte Bilder und/oder Schriften). Das Kontrollkriterium für
> angelieferte Kundenbilder war wirklich einfach: Hat der Server ein Lay
> gemacht, war alles i.O.;
Ist das wirklich ein zuverlässiges Kriterium? Der Server "weiß" in
diesem Fall doch noch gar nicht, auf welchem Ausgabegerät er drucken
soll. Angenommen, er kriegt ein PS3-EPS (gibt's eigentlich nicht, ich
weiß ;-), macht davon ein .lay, weil das ja für ihn in Ordnung geht, und
eines der Ausgabegeräte (Belichter, Proof, sw-Drucker) kann nur PS Level
1. Was passiert dann? Auch ein "Simulieren" von PS3-Features auf einem
Level-1-Gerät dürfte in vielen Fällen schwierig sein ...
> wenn nicht, musste ich das Bild prüfen und ggf. neu
> anfordern. D.h. nach einer halben Stunde wusste ich meistens bereits, was
> ich alles vom Verlag nachordnern musste. Gegen Mittag war das Zeugs dann
> meistens da und ich machte die restlichen Seiten startklar, indem ich sie in
> eine "Print-to-Disk" Queue auf dem Server schickte, der Jobs als
> PostScript-Dateien mit inkludierten Grobbildern in einem Verzeichnis ablegte
> und parallel auf ein RIP ballerte (immer noch mit Grobbildern der eigenen
> Scans aber schon mit Feinbildern der vom Verlag gelieferten Bilder und v.a.
> Anzeigen-EPS). Dieses RIP erzeugte TIFFs, die automatisch nach 24 Stunden
> gelöscht wurden.
Diese TIFFs wurden aber nie verwendet, oder? Sozusagen rippen nach
/dev/null nur um zu sehen, ob's läuft? Gut, machen wir prinzipiell
genauso, nur das wir die Teilchen auf einem Laserdrucker ausdrucken.
> ... auf das Proof geschoben, das dann über Nacht die Seiten (als
> Doppelseiten mit eingestreuten Schneidzeichen) ausgegeben hat.
Sofern nicht irgendwann die Tinte leer war ;-)
> Sollten an Seiten nur Bildkorrekturen anfallen, so wurden die in der
> Retuscheabteilung gemacht; in diesen Fällen musste ich die Xpress-Seite
> nicht mehr anfassen, da ja sonst nichts Inhaltliches an der Seite geschehen
> ist. Es reichte völlig, die PS-Datei erneut über die OPI-Queue auf den
> Proofer zu schieben :-)
Da hätte ich so meine Probleme damit, wenn die Daten mittendrin nicht
mehr konsistent sind, also die PS-Daten vom Inhalt der ursprünglichen
Quark-Datei abweichen. Auch, wenn's bloß die Bilder sind ...
> Aber grundsätzlich ließ sich eben durch die Entzerrung normalerweise
> aufeinanderfolgender Produktionsschritte massiv Zeit sparen, sehr
> frühzeitig auf Fehler(quellen) reagieren und letzten Endes durch den
> OPI-Mechanismus die Produktionssicherheit drastisch erhöhen.
ACK.
> Ich wollte die Mechanismen damals noch weiter aufbohren, habe aber dann den
> Laden gewechselt (Cheffe hat mir vorgerechnet, daß durch die neue optimierte
> Arbeitsweise bei der Produktion des Magazins nur noch 55% der Kosten im
> Vergleich zu davor entstehen würden. Ich wollte das durch eine angenemessene
> Lohnerhöhung ein wenig relativieren, aber er hörte plötzlich ganz schlecht)
Das haben Chefs so an sich ;-)
> Ulkigerweise bin ich dann zu einer anderen Repro, die zwei andere Magazine
> für denselben Verlag machten. Dort durfte ich dann sehen, wie man OPI auch
> falsch adaptieren kann. Der Knecht, der dort ca. 2 Wochen im Monat am Rande
> des Nervenzusammenbruchs die Magazine durch die Produktion drückte, benutzte
> OPI nur, indem er beim Drucken "TIFF&EPS auslassen" im Druckdialog anwählte
> (die ließen keine Grobdaten auf dem Server automatisch erzeugen).
>
> Naja, dort wurde dann in der Folgezeit einiges umgestellt, als sie endlich
> mal kapiert hatten, was man mit OPI noch anfangen kann als nur 10 Minuten
> pro Monat je Mitarbeiter durch schnelleres Spoolen zu sparen :-)
Naja, ist ja immerhin auch schon mal was ;-)
> [Automatische Grobbild-Erstellung auf OPI-Server]
> > Da wurschtelt ein Maschinchen im Hintergrund an den Dateien rum, ohne
> > dass man ihm das explizit sagen muss.
>
> Doch, doch, das sagst Du ihm explizit, indem Du das ganze global
> einschaltetst. Auf Ordnerebene hast Du dann noch durch
> Ordnernamenkonventionen weitreichende Möglichkeiten, das Verhalten zu
> steuern, bspw. indem Du ein "%0" anhängst, was die Grobbilderzeugung für
> alle Unterordner stoppt, oder bspw. ein %144g, was dazu führt, daß Du im
> layouts Ordner Grobbilder im PNG-Format mit 144 dpi erhältst, etc. (Hint:
> Alle, die sich von Photoshop Bilder "fürs Web" runterrechnen lassen sind
> irgendwie selbst schuld ;-)
Da könntest Du jetzt aber auch mal eine Wette verlieren: Ich bin mir
sicher, dass ich mit _motivbezogener_ manueller Web-Optimierung bessere
Ergebnisse hinkriege als mit einem 08/15-Batch. Gleiches gilt IMHO auch
für Bildseparationen.
> > Das widerspricht (zumindest für mein Empfinden) der Definition eines
> > FileServers: Dateien, die ich da drauf packe, will ich auch genauso
> > wiederhaben ;-)
> Die kriegst Du ja auch so wieder! Brauchst ja bloß die Feindaten einbauen
> und fertig. Aber Du kriegst ebenso die Möglichkeit, noch mehr mit den
> Bildern zu machen, also bspw. automatisch eine Separation von bspw. Scans im
> RGB-Farbraum (mit getaggten Scannerprofilen) für eine Zeitungsrotation
> (ICC-Profil der Ausgabewarteschlange zugeordnet) on-the-fly durchführen zu
> lassen.
OK. Das ist ein Argument. BTW: Löscht Helios eigentlich automatisch die
.lay-Dateien, wenn ich die Feinbilder lösche? Wäre IMHO sinnvoll.
> >>> Wenn ich Bild X in QXP lade, dann will ich auch Bild X im Output haben.
> >>
> >> Das hast Du aber in den seltensten Fällen, schon klar, oder? Gerade Xpress
> >> hat auf extremste Weise vorgemacht, wie es sich über alle Einstellungen
> >> hinwegsetzt und Bilder auch bei ausgeschaltetem Downsampling (in Xpress)
> >> trotzdem bis zur Verstümmelung runterrechnet, etc.
> >
> > Wenn man die Bilder vorher _ordentlich_ bearbeitet, dann wird von Quark
> > da nichts downgesamplet.
>
> Hallo? Ich will meine Bilder nicht vorher prüfen müssen, ob sie den formalen
> Kriterien einer amoklaufenden Layoutapplikation entsprechen. Ich will die
> einbauen und will, daß anschließend "das Richtige passiert".
Da stellt sich aber die Frage, was im zeitlichen Ablauf sinnvoller ist.
Wenn ich mir die Bilder _vorher_ anschaue, finde ich Fehler bereits
_bevor_ ich mich ans Layout setze. Bei Deiner Version verlasse ich mich
_beim_ Layouten blindlings darauf, dass die Bilder ok sind. Und erst
wenn bei der Ausgabe der Job in der Fehlerqueue landet, kriege ich mit,
dass ein Bild z. B. nur 72 dpi hatte und ich deshalb mein Layout (falls
das Bild in keiner anderen Auflösung verfügbar ist) über den Haufen
werfen muss. Oder habe ich was übersehen?
> > AFAIK rechnet Quark erst bei mehr als doppelt zu hoher Bild-Auflösung auf
> > den korrekten Wert von 2 x Rasterweite runter.
>
> Yo. Und das manchmal auch bei Strich-TIFFs. Da kommt Laune auf :-)
Das wäre in der Tat ärgerlich. Gottseidank ist mir dieser Fehler noch
nicht untergekommen ;-)
> > Auch wenn PS 3 sicher gewisse Vorteile hat,
>
> Es ist schlichtweg Grundvoraussetzung, wenn Smooth Shades, CID-Fonts oder
> auch Sonderfarben in composite Workflows ins Spiel kommen.
>
> > ist wohl nach wie vor PS Level 2 als "Standard" anzusehen;
>
> Wer mit Xpress arbeitet (arbeiten muß) sollte hier einfach durch PS Level 1
> ersetzen. Kommt eher hin :-(
Funktioniert aber trotzdem erstaunlich gut. Wie sieht das eigentlich bei
QXP 5 bzw. dem angekündigten QXP 6 aus? Wurde da die PS-Engine
verbessert / aktualisiert?
> > insbesondere, weil man eigentlich ruhigen Gewissens davon ausgehen kann,
> > dass dieses Format jeder verarbeiten kann.
>
> Es kann aber nicht mehr alles transportieren, was heute von Software
> eingesetzt wird. Wenn man in InDesign vernünftig mit den Fähigkeiten des
> Programms umgeht, dann kommt man an PS 3 nicht herum.
<Vermutung>
Wobei insbesondere InDesign wieder für die lange vergessenen PS-Fehler
und Ausgabe-Probleme sorgt, die man zuletzt vor 10 Jahren auf Linotronic
RIP-20 antraf ;-)
</>
> > Womit wir wieder OT wären *freu*
>
> Absolut OT, soz. ;-)
>
> Und aufgrund des Mammut-Posting gleich die Ankündigung, mich eine Woche
> dezent zurückzuhalten (Quantitätskompensation :-)
Sei Dir gegönnt ;-)
Ciao
Achim,
sich fragend, ob bei Sehnenscheidenentzündung in beiden Unterarmen
bereits Frührente beantragt werden könnte ;-)
Georg Lutz
ich muss mich hier auchmal 'einklinken' ich bin auch Helios anwender und
habe eigentlich nur gute Erfahrungen mit dem Produkt gemacht.
Ein Paar Sachen sind mir unklar, und ich denke in der Diskussion hier
mit Thomas (dem HeliosMeister) können wir dass klären, ich snippe mal
alles worauf ich mich nicht beziehe, der übsichtlichkeithalber:
> > Meistens war es aber ein Riesen-Heckmeck mit gelieferten Anzeigen-EPS,
> > fehlenden Schriften seitens der Graphiker, falsch gelieferten Bildern,
> > etc.
>
Das Theme habe ich eben mit Helios noch nicht in den Griff bekommen:
Der Server macht zwar brave Layout Dateien aus den gelieferten z.B.
FreeHand EPSen aber wenn die nicht im richtigen Farbraum sind, dann
konvertiert der Helios Server die NICHT in den richtigen. Oder habe ich
was falsch verstanden?
> > layouts Ordner Grobbilder im PNG-Format mit 144 dpi erhältst, etc. (Hint:
> > Alle, die sich von Photoshop Bilder "fürs Web" runterrechnen lassen sind
> > irgendwie selbst schuld ;-)
Das würde ich gerne wissen wie das wirklich geht!
Wenn ich dass so mache, sind die Layoutfiles nacher nicht zu öffnen.
Ich habe zB einen Ordner gemacht, der heisst:
fertig%72jmr
Da sollten dann 72dpi JPG's für Mac im RGB Farbraum im Layouts Ordner
drin landen.
Leider kann ich die Bilder im Layout Ordner mit keinem Programm auf dem
Mac Öffnen (naja ich habe PhotoShop und Grafikkonverter probiert)
Weisst Du was ich falsch mache?
> Da könntest Du jetzt aber auch mal eine Wette verlieren: Ich bin mir
> sicher, dass ich mit _motivbezogener_ manueller Web-Optimierung bessere
> Ergebnisse hinkriege als mit einem 08/15-Batch. Gleiches gilt IMHO auch
> für Bildseparationen.
>
Wieviel Zeit hast Du bzw. Dein Kunde? Wieviel Geld gibt er dafür aus?
Natürlich wird dass 'per Hand' besser aber wer zahlt dass? Dein Chef?
Dein Kunde?
>
> OK. Das ist ein Argument. BTW: Löscht Helios eigentlich automatisch die
> .lay-Dateien, wenn ich die Feinbilder lösche? Wäre IMHO sinnvoll.
Nein, Wenn Du Den Bilder Ordner löschst, dann löscht er auch die
Grobdaten. Simpel
Für mich ist ein großer Stolperstein im Helios Workflow die falsche
interpretation von eingefärben Graustufen TIFF's in Xpress.
Ansonsten bin ich echt happy mit unserer SunUltra mit Solaris die aber
in 2 Wochen gegen einen IntelXenon Dual 2,4 Ghz mit Linux und Helios
ausgetauscht wird.
Gruss
Georg
Thomas Kaiser
<news:1fpiqut.auatlm12ktfuoN%use...@dtpd.com>:
> RIP-Zeit bei unverändertem /ImageMemory-Wert: 283 Sekunden
> RIP-Zeit bei /ImageMemory = 20000000: 147 Sekunden
>
> Das enspricht fast einer Verdoppelung der Geschwindigkeit!
Sach ich doch :-)
BTW: Das gehört _unter_anderem_ bei Neukunden von mir mit zu dem
Programmpaket "Workflow-Optimierung ohne Mehrkosten", das viele Leute im
nachhinein dazu bewegt ab und an in die Tischkante zu beißen (so von wegen
"Arghh... hätten wir das nur früher gewusst" ;-)
> @Thomas: Danke für den Tipp, hast Dir soeben zur versprochenen Tasse
> Kaffee noch eine Mohnschnecke hinzuverdient ;-)
Na, wart nur. Irgendwann hole ich mir beides ab :-)
Gruss,
Thomas, der aber eher eine Nußschnecke präferiert
Thomas Kaiser
[AGFA Normalizer]
> die Möglichkeit, zunächst separiert auszugeben und damit auch aus Quark
> sämtlich Überfüllungen mitzunehmen in Verbindung mir der PAP-Unterstützung
> des Normalizers durchaus verlockend gewesen wäre.
Kommt drauf an, wann Du das versucht hättest und ob Du Dich auf etwas
speziellere Geschichten wie bspw. Sonderfarben im Job eingelassen hättest.
Ich habe mir die Lösung auf einer Messe mal angeschaut (und prompt einen
Standverweise von AGFA kassiert, weil ich dauernd nachgefragt habe und mir
keiner Antworten geben konnte bzw. ich wiederholt drauf hingewiesen habe,
daß mir Quatsch erzählt wurde) und einmal live bei einer italienischen
Druckerei in einer Produktionsumgebung (ist allerdings schon 3 Jahre her).
Ich fand die Diskrepanz zwischen Marketingversprechen und Realität mal
wieder erschreckend (wie leider schon zu oft bei AGFA)
>> Und in "Umbruch-RZ" lagen schließlich die von mir benutzten
>> Xpress-Dateien, benannt nach einer simplen Konvention
>> (Auftragsnummer_Seitenzahl_Beschreibung)
>
> Wo kamen die denn her? Ich konnte in Deiner Beschreibung überhaupt keine
> Zeit für den eigentlichen Satz entdecken?
Den Satz an sich haben ja bereits externe Grafiker für den Verlag erledigt.
Wir bekamen quasi ein Xpress-Dokument, in dem Layoutscans und Anzeigen
fertig platziert waren. Dieses kopierte ich dann aus den "Kundendaten" raus
(einfach um immer die originale Kundendatei noch präsent zu haben, falls ich
Mist baue oder sich Probleme ergeben und man die Quelle lokalisieren möchte)
und sicherte es in den "Umbruch-RZ" Ordner nach vereinbartem Namenschema
(Auftragsnummer_...) damit die Druckjobs anschließend auf dem Server
automatisch zu richtigem auftragsbezogenem Accounting und Zusortierung
führen.
>> Ein Skript von mir hat dann auf dem Server diese Rohscans in aller Frühe
>> in den "Feinbilder ok" Ordner kopiert, dort ein Grobbild erzeugt und das
>> eigentliche Feinbild in diesem Ordner wieder gelöscht (denn die Rohscans
>> waren ja noch nicht auskorrigiert und daher nicht prooftauglich)
>
> Und wer hat wann die Freisteller gemacht?
Die Retuschemädels und manchmal ich, wenn es eilig war oder ich mit einem
schönen weichen Freisteller rumposen wollte ;-)
Ich habe meistens das nicht freigestellte Bild in einem Polygonrahmen
platziert; der eigentliche Freisteller ist dann später am Nachmittag und
meistens wenn ich den Laden schon wieder verlassen hatte, erzeugt worden.
> Falls es welche gegeben hat, müssten die ja bereits in diesem Stadium der
> Produktion fertig gewesen sein wegen Textumfluß und so ...
Für den Textfluß sind sie nicht nötig gewesen, da ja bereits in den
angelieferten Xpress-Dateien entsprechende Polygonrahmen den Textfluß für
Freisteller definierten.
>> Das Kontrollkriterium für angelieferte Kundenbilder war wirklich einfach:
>> Hat der Server ein Lay gemacht, war alles i.O.;
>
> Ist das wirklich ein zuverlässiges Kriterium?
Ja.
> Der Server "weiß" in diesem Fall doch noch gar nicht, auf welchem
> Ausgabegerät er drucken soll.
Aber er kann damit umgehen und zeigt mir das, was er kann auch im Grobbild.
Wenn ich im Grobbild manche Sachen wie bspw.
> Angenommen, er kriegt ein PS3-EPS (gibt's eigentlich nicht, ich weiß ;-),
Vor allem "damals" nicht.
> macht davon ein .lay, weil das ja für ihn in Ordnung geht, und eines der
> Ausgabegeräte (Belichter, Proof, sw-Drucker) kann nur PS Level 1. Was
> passiert dann?
Beim Aufziehen von "Workflows" sollte man derlei natürlich berücksichtigen,
was für mich bedeutet, daß Level 1 Geräte einfach im internen Betrieb keinen
Platz mehr haben (wohl aber bei Grobbildern, bei denen man durch gezielte
Parametrisierung des Servers dafür sorgen kann, daß diese auch für externe
Grafiker, die noch einen originalen Apple Laserwriter besitzen eine Level 1
taugliche "printable Preview" beinhalten). Richtschnur war damals einfach PS
Level 2.
Aber um auf die Frage zurückzukommen: Helios hat in den OPI-Server (aktuell
richtigerweise ImageServer getauft) entsprechenden Support eingebaut, der
beim Austausch von Dateien anhand der Queue-Konfiguration (d.h. PPD des
Ausgabegeräts) den PS-Level ausliest und berücksichtigt. Bspw. werden
JPEG-komprimierte EPS auf Level 1 Geräten dekomprimiert geschickt (da ja die
ganzen Encode/Decode Filter erst mit PS Level 2 kamen), etc.
Wie weit das auch hinsichtlich einzelner Konstrukte im PS-Code geht,
entzieht sich aber meiner Kenntnis, da ich -- wie schon betont -- Level 1
Geräte seit Jahren deaktiviere, wenn sie mir in den Weg kommen (bringt wegen
den ganzen Limitationen mehr Ärger als Nutzen)
> Auch ein "Simulieren" von PS3-Features auf einem Level-1-Gerät dürfte in
> vielen Fällen schwierig sein ...
Ich müsste mal nachschauen, was momentan aktuell ist. Aber mit den letzten
Versionen (in Helios-Sprech "CD 017" genannt) wurden in so einem Fall bspw.
SmoothShades von PS 3 in CMYK Bildobjekte für Level 1 Interpreter gewandelt.
Daß hierbei aber Kompromisse eingegangen werden müssten, die oftmals nicht
wirklich sinnvoll realisierbar sind, ist natürlich klar.
>> Dieses RIP erzeugte TIFFs, die automatisch nach 24 Stunden gelöscht wurden.
>
> Diese TIFFs wurden aber nie verwendet, oder?
Manchmal angeguckt, um Überfüllungen zu beurteilen, um dann mit Verlag zu
klären, ob man bspw. eine gelieferte Anzeige noch nachbearbeiten soll, bevor
sie auf's Proof geht.
> Sozusagen rippen nach /dev/null nur um zu sehen, ob's läuft?
Yo. Allerdings mit der endgültigen Belichterauflösung von 2540 dpi und dann
runtergerechnet auf 300 dpi. Wie es der Zufall wollte, standen bei uns vor
Ort und bei dem CtP-Dienstleister im Kurpfälzischen identische Delta-RIPs
von Heidelberg.
>> ... auf das Proof geschoben, das dann über Nacht die Seiten (als
>> Doppelseiten mit eingestreuten Schneidzeichen) ausgegeben hat.
>
> Sofern nicht irgendwann die Tinte leer war ;-)
Das war alles kalkulierbar (auch die Proofzeiten!) und mitunter auch meine
Aufgabe, diesen Zustand rechtzeitig herbeizuführen. Da bedingt durch die
Verlässlichkeit des Proofs, über Nacht hinweg unbeaufsichtigt laufen zu
können, über den Tag hinweg die Kiste frei für Schnellschüsse oder eben
Bildstreckenproofs war, hat man halt bei vorhersehbar knappem Tintenstand
einfach fette Bildstrecken oder auch "meine" Doppelseiten untertags geprooft
(war ja bloß eine Printserver-Queue von "Halten" auf "Drucken" stellen), und
dann wurde am Abend eben der "Tintenkanister" der entsprechenden Farbe
getauscht.
>> Sollten an Seiten nur Bildkorrekturen anfallen, so wurden die in der
>> Retuscheabteilung gemacht; in diesen Fällen musste ich die Xpress-Seite
>> nicht mehr anfassen, da ja sonst nichts Inhaltliches an der Seite geschehen
>> ist. Es reichte völlig, die PS-Datei erneut über die OPI-Queue auf den
>> Proofer zu schieben :-)
>
> Da hätte ich so meine Probleme damit, wenn die Daten mittendrin nicht
> mehr konsistent sind, also die PS-Daten vom Inhalt der ursprünglichen
> Quark-Datei abweichen. Auch, wenn's bloß die Bilder sind ...
Ach weißt Du, ich habe bei Katalogproduktionen mit PDF-Handshake schon aus
einer Variante eines Katalogs (A4 4c für Digitaldruck) nur durch Grob-/
Feinbild-Austausch und Nachbearbeitung durch PitStop Server eine zweite (A5
s/w für Rollenoffset) erzeugt.
Die 2500 Seiten wurden in der A4-Variante produziert, korrigiert und
freigegeben und sukzessive auf das Digitaldruck-RIP geschickt. Als das
fertig war, habe ich zwei Ordner, in denen PDFs lagen, umbenannt und die
LowRes-PS-Dateien direkt auf dem Server per lpr Kommando in eine andere
OPI-Queue geschossen. Fertig.
In den Katalogseiten waren Lays der Seitenhintergründe (die als PDF-Dateien
vorlagen) eingebaut, waren entsprechende Kapitelbezeichnungen wiederum als
Lays von PDFs drübergelegt, etc. etc.
Und für die A5-Variante musste ich nun nur quasi die Pfade von PDF für 4c/A4
auf die für 1c/A5 umbiegen und erneut spoolen (und den PitStop Server halt
noch die Bilder runterrechnen lassen, in s/w wandeln, etc.)
Aber der Vorteil war der, daß man einfach verbindlich *eine* Variante
korrigiert und freigegeben hat und bedingt durch simplen Austausch der Pfade
zu den PDF absolut sicher sein konnte, daß auch der andere Katalog exakt dem
erwarteten Ergebnis entspricht (was man bei manueller Vorgehensweise IMO
niemals garantieren könnte, da Menschen keine Maschinen sind)
Wenn man den Vorgang begriffen hat und sich auf der Zunge zergehen hat
lassen, was damit für Produktionsschmankerl möglich sind, dann zerstreuen
sich derlei Bedenken, die meisten "aus dem Bauch heraus" kommen, erstaunlich
schnell ;-)
>> Du im layouts Ordner Grobbilder im PNG-Format mit 144 dpi erhältst, etc.
>> (Hint: Alle, die sich von Photoshop Bilder "fürs Web" runterrechnen lassen
>> sind irgendwie selbst schuld ;-)
>
> Da könntest Du jetzt aber auch mal eine Wette verlieren: Ich bin mir
> sicher, dass ich mit _motivbezogener_ manueller Web-Optimierung bessere
> Ergebnisse hinkriege als mit einem 08/15-Batch.
Ich sprach nicht von besser sondern nur von unaufwändiger. Und ob die Leute
nun einen Photoshop-Batch laufen lassen oder vorher nachdenken und am Server
einen Ordner richtig benennen, dürfte in beiden Fällen nicht viel mit
manueller Optimierung aber sehr wohl viel mit gesparter Zeit zu tun haben.
BTW: In der neuen ImageServer Version ist auch ein Hotfolder-Mechanismus
eingebaut, mit dem man -- entsprechende Kenntnis der Helios CLI-Tools
vorausgesetzt -- verdammt mächtige Bildkonvertierungen direkt auf dem Server
anstossen kann.
> Gleiches gilt IMHO auch für Bildseparationen.
Naja, jetzt streifen wir das Thema Farbmanagement und deren philosophische
Randerscheinungen aber gewaltig ;-)
Nur so viel: Wenn ein Bild einer Farbraumtransformation unterzogen werden
soll, dann ist das ein automatisierbarer Vorgang, da nur die Parameter
bekannt sein müssen (Quell-, Zielprofil, Rendering Intent, ColorMatching
Method). Daher ist auf jedem Gerät, das diese Sachen sauber berücksichtigt
bzw. umsetzt, mit identischen Ergebnissen zu rechnen.
Wenn Du von "qualitativ" besseren "Separationen" redest, kommt
Bildoptimierung ins Spiel und da die Frage: Mache ich die im Original (was
ist das Original? Das Dia, der RGB-Scan oder die farbraumtranformierte CMYK
Version davon? ;-) oder mache ich die in einer beliebigen digitalen Variante
des Bildes?
Ellenlanges Thema, sollten wir uns hier aber schenken. Nur noch so viel: Ich
habe gaudihalber mit LinoColor auch schon in LAB LH direkt auf den Server
gescannt (und alle Bildoptimierungen im LCH-Arbeitsfarbraum direkt in
LinoColor in den LabLH Bildern vorgenommen). Das waren für mich per
Definition die farbrichtigen Originale. Und diese sind zu meiner vollsten
Zufriedenheit während der Ausgabe vom Server anhand eines guten Zielprofils
separiert worden.
> BTW: Löscht Helios eigentlich automatisch die .lay-Dateien, wenn ich die
> Feinbilder lösche? Wäre IMHO sinnvoll.
Kommt halt drauf an. Genau dieses Feature (die Grobdaten eben nicht auf
Gedeih und Verderb mit den Feindaten zu koppeln) macht für mich eine der
grössten Stärken des Servers aus! Ohne diese Funktionalität sind nahezu alle
erweiterten Workflows, die wirklich von den OPI-Funktionalitäten Gebrauch
machen (also alles, was über "schneller spoolen" hinausgeht!) weitestgehend
nutzlos.
Was man dagegen machen kann, ist ein nächtlicher Cronjob, der nach
Lay-Waisen sucht (das ist maximal ein Dreizeiler, da Helios einem einen
ganzen Sack sehr effizienter CLI-Tools beipackt).
Allerdings habe ich dieses Feature noch *nie* gebraucht, da ich halt
Verfechter von klaren Ordnerstrukturen bin.
> Wenn ich mir die Bilder _vorher_ anschaue, finde ich Fehler bereits
> _bevor_ ich mich ans Layout setze.
Ja und? Warum soll ich Fehler aktiv suchen? Das ist ja fast so, wie jeden
Tag bei Versiontracker zumzuwühlen, ob es nicht neue Werkzeuge gibt, die
Probleme lösen könnten, die man nie zuvor hatte ;-)
> Bei Deiner Version verlasse ich mich _beim_ Layouten blindlings darauf,
> dass die Bilder ok sind.
Nein. Ich verlasse mich darauf, daß sie gewissen formalen Kriterien genügen,
die die Ausgabe dieser Bilder sicherstellen (Farbräume, Bilder vom
Dateiformat her okay, d.h. keine defekten Dateien). Das sagt nichts darüber
aus, ob da Bilder evtl. nur 72 dpi haben (was sie oft hatten, da im Verlag
manches mal auch Bilder direkt aus dem Web gezogen wurden) oder farblich
völlig daneben sind, etc.
Was dagegen passierte, ist, daß manches mal beim Einbau der Grobbilder in
XPress bei mir die Frage aufkam, ob das ernst gemeint sei (weil Bild bspw.
viel zu flau oder von der Farbstimmung nicht mit den anderen platzierten
Bildern vereinbar --> Telefonat mit Verlag und entweder Korrekturansweisung
bekommen oder eben nicht)
> Und erst wenn bei der Ausgabe der Job in der Fehlerqueue landet,
Wieso sollte er da landen? Sicher nicht wegen 72 dpi, denn das prüfe ich
nicht.
> kriege ich mit, dass ein Bild z. B. nur 72 dpi hatte und ich deshalb mein
> Layout (falls das Bild in keiner anderen Auflösung verfügbar ist) über den
> Haufen werfen muss.
72 dpi bedeutet doch erstmal gar nichts. Wenn ich so ein Bildchen auf 20%
skaliere, erhält es eine effektive Auflösung von 360 dpi und ist damit mehr
als ausreichend für Offsetdruck (sogar 80er Raster). Es kommt eben immer auf
den Einsatzzweck des Bildes an. Wenn so ein Bild partout als Aufmacher mit
100% eingebaut werden soll, dann fällt das allerspätestens auf dem Proof
auf, daß das nicht der Weisheit letzter Schluss ist.
> Oder habe ich was übersehen?
Glaub schon, bzw. kam anscheinend nicht klar genug rüber, daß die Seiten
schon fertig layoutet vom Verlag kamen.
Als ich das Magazin übernommen hatte, bin ich relativ bald zum Verlag
gefahren um ein bisserl Smalltalk abzusetzen und den Vorschlag anzubringen,
eine halbtägige Schulung (kostenlos) für die Grafiker zu machen (denn was
die teilweise ablieferten kannte ich schon von vorher als Oberdatenklempner
des Betriebs). Das hat sich insgesamt für beide Seiten gelohnt, da dort dann
manche Zusammenhänge bspw. hinsichtlich Bildauflösung <--> Platzierung im
Layout oder Farbräumen und den Gefahren verlustbehafteter Bildkompression,
etc. klarer wurden und sie eher bereit waren, auf Kompetenzgerangel zu
verzichten und kritische Bilder (bzw. deren Retusche und Optimierung) von
vorneherein der Obhut des "freundlichen Dienstleisters" zu überlassen.
>> Wer mit Xpress arbeitet (arbeiten muß) sollte hier einfach durch PS Level 1
>> ersetzen. Kommt eher hin :-(
>
> Funktioniert aber trotzdem erstaunlich gut.
Yo. Solange man halt keinen Composite Workflow einsetzt. Dann beginnen die
Probleme, da für manche Sachen (Bildobjekt mit mehr als einer Sonderfarbe)
schon nicht mal mehr in PS Level 2 Mittel und Wege bereitstehen, sie in
einem Composite Workflow zu lösen.
Sorry, aber es ist halt einfach Tatsache: Wer moderne composite Workflows
einsetzen will (und dabei mehr als Schwarzweiß und CMYK macht) kommt um
PostScript 3 irgendwie nicht mehr herum.
> Wie sieht das eigentlich bei QXP 5 bzw. dem angekündigten QXP 6 aus? Wurde
> da die PS-Engine verbessert / aktualisiert?
Xpress 5 leistet sich die selben Patzer, die schon für Xpress 4 als hochnot
peinlich anzusehen waren (zumindest laut Robert Zacherl, der ja diesbzgl.
auf der pdfzone-prepress Mailingliste mehr als einmal Aufklärung betrieben
hat)
> Wobei insbesondere InDesign wieder für die lange vergessenen PS-Fehler
> und Ausgabe-Probleme sorgt, die man zuletzt vor 10 Jahren auf Linotronic
> RIP-20 antraf ;-)
Naja, der direkte PDF-Export hat es halt in sich (weil so nah dran am
PDF-Standard, daß man merkt, daß es leider kein Ausgabegerät gibt, das da
noch mithalten kann). Aber wenn man ein PS3-RIP unterm Tisch stehen hat
(<hüstel>) dann ist das doch alles kein Problem, oder?
Das Werkzeug muß halt zusammenpassen; Du spannst in eine Hilti ja auch nicht
verrostete Nachkriegsbohrer, oder?
>> Und aufgrund des Mammut-Posting gleich die Ankündigung, mich eine Woche
>> dezent zurückzuhalten (Quantitätskompensation :-)
>
> Sei Dir gegönnt ;-)
Ach je, so wie es aussieht, steht heute wieder remote Serveradministration
an, d.h. kurz was tun --> abwarten, was Kunde sagt --> kurz was tun,
abwarten...
An solchen Tagen häufen sich die Postings dann irgendwie wieder weil man in
den Wartepausen sonst kaum was Sinnvolles anstellen kann :-(
> sich fragend, ob bei Sehnenscheidenentzündung in beiden Unterarmen
> bereits Frührente beantragt werden könnte ;-)
Ach, hast Du damit Probleme?
Gruss,
Thomas
Thomas Kaiser
<news:georg-9ACA1D....@mail.snafu.de>:
> Der Server macht zwar brave Layout Dateien aus den gelieferten z.B.
> FreeHand EPSen aber wenn die nicht im richtigen Farbraum sind, dann
> konvertiert der Helios Server die NICHT in den richtigen.
Kurz zur Klarstellung: Ein Freehand EPS ist *kein* Bilddaten-EPS (das sich
dadurch auszeichnet, daß im Prinzip nur eine Bit- bzw. Bytemap in einem
EPS-Mäntelchen verpackt ist) sondern erstmal ein *vollwertiges* EPS. In so
einem kann bspw. das kleine Fraktal.eps platziert sein, das mit "echtem"
PostScript-Code zur Sachen geht.
Damit derlei EPS farbangepasst werden könnten, müsste auf dem Server ein RIP
existieren, der dieses EPS interpretiert und was Neues daraus baut (d.h.
also bspw. eine Umwandlung von PostScript-Programmen, die Linien zeichnen,
in eine Aneinanderreihung von graphischen Primitiven umwandeln -->
eigentlich all das, was der Distiller bei der Konvertierung zu PDF macht)
> Oder habe ich was falsch verstanden?
Yepp. Farbmanagement geschieht auf Bilddateiformate (und dazu gehören
explizit keine *echten* EPS, die auch vektorisierte Elemente, Schrift und
v.a. Programmcode enthalten können) und -- falls Du PDF-Handshake hast --
auf PDF-Dateien.
D.h. der einzige Weg, das hinzubekommen, ist entweder der Kauf von
PDF-Handshake und die Umwandlung nach PDF (da PDF als objektorientiertes
Metagrafikformat die Grundvoraussetzungen mitbringt, die für Colormanagement
auf Objektebene eben nötig sind) oder aber eine umfangreichere Shoppingtour
bei OneVision ;-)
[Ordnernamenskonventionen für Grobbildformat]
> Das würde ich gerne wissen wie das wirklich geht!
> Wenn ich dass so mache, sind die Layoutfiles nacher nicht zu öffnen.
"Öffnen" und "Platzieren" sind zwei paar Schuhe. Ich vermute sehr stark, daß
in der Datafork noch das originale Freehand EPS steckt, da
1) im ImageServer kein vollständiges RIP eingebaut ist, der beliebige EPS
rendern könnte
2) noch eine zweite Regel zuschlägt, die seit OPI 2.1 (AFAIR) dafür sorgt,
daß Lays von EPS nicht größer werden als das Feinbild (was ja
normalerweise sein könnte, wenn man ein JPEG komprimiertes EPS hat und
für Lays Kompression ausgeschaltet ist)
Bei Dir dürfte aber Regel 1 zuschlagen.
> Ich habe zB einen Ordner gemacht, der heisst:
>
> fertig%72jmr
Stimmt von der Syntax her, allerdings sind die Ausgangsdaten eben nicht für
diesen Zweck geeignet, da Helios kein generisches RIP im ImageServer
eingebaut hat. Mittels PrintPreview und einem Skript wäre das Ansinnen
hingegen leicht zu realisieren, aus den EPS entsprechende JPGs zu machen.
> Für mich ist ein großer Stolperstein im Helios Workflow die falsche
> interpretation von eingefärben Graustufen TIFF's in Xpress.
Du hast aber auf den Xpress-Arbeitsplätzen die "HELIOS OPI TuneUp" XTension
im Einsatz, die dieses Problem (das daraus resultiert, daß Xpress in den
OPI-Kommentaren die Einfärbung des Hintergrunds nicht von sich aus
mitschickt) adressiert?
> Ansonsten bin ich echt happy mit unserer SunUltra mit Solaris die aber
> in 2 Wochen gegen einen IntelXenon Dual 2,4 Ghz mit Linux und Helios
> ausgetauscht wird.
Na, dann viel Spaß mit dem USB-Dongle unter Linux ;-)
Das ist so ein Punkt, an dem man MacOS X wieder zu schätzen lernt. Dort
steckt man den Dongle und es läuft. Unter Linux kann man im BIOS rumfutteln
(Tipp: Falls bei Euch vorhanden, dann "MPR-1.4" deaktivieren), den richtigen
Kernel backen, diversen Problemen mit Interrupt Routing oder zu schnellem
Laden des USB-Subsystem nachlaufen, falsches USB-Modul geladen), etc.
Nervig :-(
Gruss,
Thomas, der für die USB-Schnelldiagnose empfiehlt, eine Knoppix 3.1
bereitzuhalten, falls auf dem Server SuSE laufen soll
Georg Lutz
Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Georg Lutz schrieb am 29.01.2003 9:03 Uhr in
> <news:georg-9ACA1D....@mail.snafu.de>:
>
> > Der Server macht zwar brave Layout Dateien aus den gelieferten z.B.
> > FreeHand EPSen aber wenn die nicht im richtigen Farbraum sind, dann
> > konvertiert der Helios Server die NICHT in den richtigen.
>
> Kurz zur Klarstellung: Ein Freehand EPS ist *kein* Bilddaten-EPS (das sich
> dadurch auszeichnet, daß im Prinzip nur eine Bit- bzw. Bytemap in einem
> EPS-Mäntelchen verpackt ist) sondern erstmal ein *vollwertiges* EPS. In so
> einem kann bspw. das kleine Fraktal.eps platziert sein, das mit "echtem"
> PostScript-Code zur Sachen geht.
Ja, früher haben wir das immer 'verschachtelte EPSe' genannt. Ich kenne
sowas, wir hatten einen Kunden, der war weltmeister darin, EPSe in EPS
zu laden und diese dann wieder als EPS zu sichern ;-)
>
> Damit derlei EPS farbangepasst werden könnten, müsste auf dem Server ein RIP
> existieren, der dieses EPS interpretiert und was Neues daraus baut (d.h.
> also bspw. eine Umwandlung von PostScript-Programmen, die Linien zeichnen,
> in eine Aneinanderreihung von graphischen Primitiven umwandeln -->
> eigentlich all das, was der Distiller bei der Konvertierung zu PDF macht)
>
> > Oder habe ich was falsch verstanden?
>
> Yepp. Farbmanagement geschieht auf Bilddateiformate (und dazu gehören
> explizit keine *echten* EPS, die auch vektorisierte Elemente, Schrift und
> v.a. Programmcode enthalten können) und -- falls Du PDF-Handshake hast --
> auf PDF-Dateien.
PDF Handshake habe ich leider nicht. Ich bin noch am Haden ob ich das
kaufen soll oder nicht. Es kostet ja ne stange Geld. Wenn ich bei Promo
anrufen, kriege ich natürlich ein 'Verkaufsgespräch' Ein Mitarbeiter von
mir liebt die PitStop produkte (server) der ist aber auch recht teure.
Weisst Du ob man beides braucht? Handskake und Pitstop oder kann man mit
einer Sache 'beginnnen'?
Meine Berührungspunkte bezüglich PDF sind, dass wir Seiten als
hochaufgelöste PDFe an eine Druckerei für Ctp liefern müssen. Das
funktioniert eigentlich einwandfrei. Nun hat der Mitarbeiter erzählt, es
wäre toll, wenn wir den Server hätten (ca. 4.000 ¤ *autsch*) Man könnte
sich eine manuelle Kontrolle sparen. Denkst Du auch so?
>
> D.h. der einzige Weg, das hinzubekommen, ist entweder der Kauf von
> PDF-Handshake und die Umwandlung nach PDF (da PDF als objektorientiertes
> Metagrafikformat die Grundvoraussetzungen mitbringt, die für Colormanagement
> auf Objektebene eben nötig sind) oder aber eine umfangreichere Shoppingtour
> bei OneVision ;-)
Nein Danke. OneVision ist mir echt zu heftig. Die Software ist das
teuerste was ich am Markt gesehen habe. So schlimm ist es dann doch
nicht... ;-)
>
> [Ordnernamenskonventionen für Grobbildformat]
> > Das würde ich gerne wissen wie das wirklich geht!
> > Wenn ich dass so mache, sind die Layoutfiles nacher nicht zu öffnen.
>
> "Öffnen" und "Platzieren" sind zwei paar Schuhe. Ich vermute sehr stark, daß
> in der Datafork noch das originale Freehand EPS steckt, da
>
> 1) im ImageServer kein vollständiges RIP eingebaut ist, der beliebige EPS
> rendern könnte
>
> 2) noch eine zweite Regel zuschlägt, die seit OPI 2.1 (AFAIR) dafür sorgt,
> daß Lays von EPS nicht größer werden als das Feinbild (was ja
> normalerweise sein könnte, wenn man ein JPEG komprimiertes EPS hat und
> für Lays Kompression ausgeschaltet ist)
>
> Bei Dir dürfte aber Regel 1 zuschlagen.
Ja Regel 1 :-)
Gibt es sowas wie ein 'vollständiges RIP' im Server? Ggf. über einen
Distiller oder?
>
> > Ich habe zB einen Ordner gemacht, der heisst:
> >
> > fertig%72jmr
>
> Stimmt von der Syntax her, allerdings sind die Ausgangsdaten eben nicht für
> diesen Zweck geeignet, da Helios kein generisches RIP im ImageServer
> eingebaut hat. Mittels PrintPreview und einem Skript wäre das Ansinnen
> hingegen leicht zu realisieren, aus den EPS entsprechende JPGs zu machen.
Habe kein Print Preview :-(
Sind auch nur ca. 200 FreeHand EPSe. Der Azubi stöhnt zwar, aber in max.
2 Tagen ist der durch damit.
>
> > Für mich ist ein großer Stolperstein im Helios Workflow die falsche
> > interpretation von eingefärben Graustufen TIFF's in Xpress.
>
> Du hast aber auf den Xpress-Arbeitsplätzen die "HELIOS OPI TuneUp" XTension
> im Einsatz, die dieses Problem (das daraus resultiert, daß Xpress in den
> OPI-Kommentaren die Einfärbung des Hintergrunds nicht von sich aus
> mitschickt) adressiert?
Haben wir nicht! Noch nie gehört, weisst Du wo es den gibt? bei Helios?
>
> > Ansonsten bin ich echt happy mit unserer SunUltra mit Solaris die aber
> > in 2 Wochen gegen einen IntelXenon Dual 2,4 Ghz mit Linux und Helios
> > ausgetauscht wird.
>
> Na, dann viel Spaß mit dem USB-Dongle unter Linux ;-)
Wie jetzt? Was braucht denn einen USB Dongle? Die Helios Suite läuft
jetzt mit Dongel? Habe ich was übersehen? Im Moment nutzen wir noch die
'alte' Version ich glaube 2.1 Diese wird über MachID 'geschützt'
Des weitern soll noch ein Cumulus Server auf der Maschine laufen. Das
wars dann. Ich bin sehr auf hiopsboteschaften von Dir gespannt.
Das wird ja langsam sehr interessant. Mein Händler hat mir davon NIX
erzählt.
Bitte sage mir wofür man den USB Dongle braucht!
Thomas Kaiser
<news:georg-1A253A....@mail.snafu.de>:
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> [...] Ein Freehand EPS ist [...] ein *vollwertiges* EPS. In so einem kann
>> bspw. das kleine Fraktal.eps platziert sein, das mit "echtem" PostScript-Code
>> zur Sachen geht.
>
> Ja, früher haben wir das immer 'verschachtelte EPSe' genannt.
Wobei da nicht die Verschachtelung das Problem ist (die nur hinsichtlich der
Komplexität und Problemen, wenn der Graphic State nicht sauber wieder
hergestellt wird, wenn eines der ineinander geschachtelten EPS "verlassen"
wird) sondern tatsächlich die Natur des EPS an sich (als gekapseltes Stück
Programmcode, der zufälligerweise ein graphisches Abbild auf eine Seite
bringen soll)
> Ich kenne sowas, wir hatten einen Kunden, der war weltmeister darin, EPSe
> in EPS zu laden und diese dann wieder als EPS zu sichern ;-)
Macht ja auch Spaß :-)
> PDF Handshake habe ich leider nicht. Ich bin noch am Haden ob ich das
> kaufen soll oder nicht.
Du musst Dir halt die einzelnen Features mal genau anschauen und
durchchecken, was Du davon brauchen kannst (und wie das mit PitStop Server
zu vergleichen ist). Irgendwie schon wieder fast zu komplex, um das hier
anzuschneiden. Vielleicht einen eigenen Thread aufmachen?
> Gibt es sowas wie ein 'vollständiges RIP' im Server? Ggf. über einen
> Distiller oder?
Ein Distiller ist erstmal ein "vollständiges RIP", das allerdings in das
objektorientierte Format PDF "rippt". Was Dir vorschwebt ist wohl etwas, das
pixelbasierte Bilder erzeugt?
Da gibt es einige Lösungen, bspw. das freie GhostScript. Das Helios eigene
PrintPreview (das ebenfalls in ein Pixelabbild einer Seite zu Prüfzwecken
rippt) hebt sich davon aber insofern ab, als das der Interpreter den
PS-Level des endgültigen Ausgabegerätes honoriert (wird aus der PPD
ausgelesen) und entsprechend seine Fähigkeiten anpasst. Wenn Du also eine
PrintPreview-Queue auf PS Level 1 einstellst und dann mit JPEG-komprimierten
Bilddaten im PS-Stream daherrumpelst, dann wird Dir der Job korrekterweise
abgebrochen (Schutz vor Überraschungen später in der Produktionskette). Was
ebenfalls noch nett ist, ist die Möglichkeit, composite Jobs in die
einzelnen Farbauszüge zu zerlegen als auch umgekehrt, von separierten Jobs
eine composite Preview zu bekommen (damit habe ich jahrelang einen Epson als
Sachproof gefüttert -- inkl. Colormanagement durch Helios, damit das
Ergebnis passabel aussah)
> Sind auch nur ca. 200 FreeHand EPSe. Der Azubi stöhnt zwar, aber in max.
> 2 Tagen ist der durch damit.
Hmm... armer Kerl. Zeig ihm doch mal, wie man mit Photoshop eine Aktion
einrichtet ;-)
["HELIOS OPI TuneUp" XTension]
> Haben wir nicht!
Doch!
> Noch nie gehört, weisst Du wo es den gibt? bei Helios?
Auf Deinem Server. Einfach das Volume "EtherShare Applications" (bzw.
aktuell "HELIOS Applications") öffnen, zum Ziel durchklicken und dann in die
XTension Ordner auf den einzelnen Macs plumpsen lassen.
BTW: Fragtest Du nicht erst kürzlich nach Schulungen? ;-))
> Die Helios Suite läuft jetzt mit Dongel?
Die Plattformen Linux und MacOS X schon. Offizielle Lesart: "Bedingt durch
häufige Hardwareschäden bei beiden Plattformen werden die Kunden durch
Bindung der machid an den Dongle im Bedarfsfall in die Lage versetzt,
schnell und unkompliziert auf Ersatzhardware auszuweichen." Ist ja erstmal
nicht schlecht, da man keinen Cold-Spare Vertrag oder sowas mehr braucht.
Wenn der Putzmann allerdings den Dongle einsaugt, steht der Laden :-)
> Habe ich was übersehen?
Sieht so aus. Aber damit bist Du nicht alleine. Es gibt auch genügend
Händler, die die Updatebeschreibungen nicht lesen und dann erst beim Kunden
mitten im Update feststellen, daß Ihnen was Essentielles entgangen ist ;-)
> Im Moment nutzen wir noch die 'alte' Version ich glaube 2.1 Diese wird über
> MachID 'geschützt'
Auf den ausgewachsenen UNIX-Plattformen wird die machid anhand der
Prozessorkennung ermittelt.
> Des weitern soll noch ein Cumulus Server auf der Maschine laufen. Das
> wars dann. Ich bin sehr auf hiopsboteschaften von Dir gespannt.
Ui, interessant. Prinzipiell steht der Kombi nichts entgegen (hat sogar
nette Vorteile, wenn man den HELIOS Companion einsetzt, der Bilder durch
direkte Interaktion mit den Helios-Tasks in Cumulus katalogisieren kann)
Du solltest bloß vor der Installation von Cumulus nachfragen, ob Canto
aktuellere Versionen hat, als die, die auf den CDs drauf sind. Ein Kunde von
mir hat nämlich ebenfalls besagte Kombination am Laufen (sowohl Solaris als
auch Linux) und hatte bis vor ein paar Wochen mit ernsthaften Problemen
hinsichtlich Stabilität des C5.5-Servers zu kämpfen, die sich dann aber dank
ein paar Nachtschichten seitens Canto in Zufriedenheit aufgelöst haben)
> Das wird ja langsam sehr interessant. Mein Händler hat mir davon NIX
> erzählt.
Dann geh einfach davon aus, daß er nicht vergessen hat, Paket "AD002" (den
Dongle) zu bestellen, daß er mit USB unter Linux schon seine Erfahrungen
gesammelt hat und eine separate USB-PCI-Karte mitbringt, die wenigtsens
einen *internen* Port hat für den Dongle (sowas gibt's tatsächlich schon).
Oder frag mal nach...
> Bitte sage mir wofür man den USB Dongle braucht!
Ermittlung der "machid".
Gruss,
Thomas
Achim Denzl
> > Da könntest Du jetzt aber auch mal eine Wette verlieren: Ich bin mir
> > sicher, dass ich mit _motivbezogener_ manueller Web-Optimierung bessere
> > Ergebnisse hinkriege als mit einem 08/15-Batch. Gleiches gilt IMHO auch
> > für Bildseparationen.
> >
> Wieviel Zeit hast Du bzw. Dein Kunde? Wieviel Geld gibt er dafür aus?
> Natürlich wird dass 'per Hand' besser aber wer zahlt dass? Dein Chef?
> Dein Kunde?
Gute Qualität muss eben auch bezahlt werden ;-)
Allerdings gibt's ja auch noch die Photoshop-Stapelverarbeitung. Und
wenn man für eine Serie von vergleichbaren Bildern die optimale
Einstellung ausgetüftelt hat, kann der Rechner zur Not auch mal über
Nacht laufen. Oder eben direkt auf dem Server, je nachdem ....
Ciao
Achim
Achim Denzl
> BTW: Das gehört _unter_anderem_ bei Neukunden von mir mit zu dem
> Programmpaket "Workflow-Optimierung ohne Mehrkosten", das viele Leute im
> nachhinein dazu bewegt ab und an in die Tischkante zu beißen (so von wegen
> "Arghh... hätten wir das nur früher gewusst" ;-)
Das glaub ich gerne ;-)
Ich finde es nur sehr schade, dass immer mehr Software-Hersteller dazu
übergehen, solche "Undocumented Features" einzubauen. Sowas gehört für
mich auf jeden Fall ins Handbuch. Wo sind diese "internen"
Distiller-Parameter eigentlich beschrieben?
> > @Thomas: Danke für den Tipp, hast Dir soeben zur versprochenen Tasse
> > Kaffee noch eine Mohnschnecke hinzuverdient ;-)
>
> Na, wart nur. Irgendwann hole ich mir beides ab :-)
Aber gerne, ist versprochen!
>
> Gruss,
>
> Thomas, der aber eher eine Nußschnecke präferiert
Ich glaube, auch das wird sich einrichten lassen ;-)
Achim Denzl
> Ich fand die Diskrepanz zwischen Marketingversprechen und Realität mal
> wieder erschreckend (wie leider schon zu oft bei AGFA)
Ich glaube, da stehen sich die "Großen" gegenseitig in Nichts nach ...
> > Wo kamen die denn her? Ich konnte in Deiner Beschreibung überhaupt keine
> > Zeit für den eigentlichen Satz entdecken?
>
> Den Satz an sich haben ja bereits externe Grafiker für den Verlag erledigt.
> Wir bekamen quasi ein Xpress-Dokument, in dem Layoutscans und Anzeigen
> fertig platziert waren.
Ah, jetzt kommen wir langsam auf des Pudels Kern und zur Antwort auf die
Frage, warum unsere Sichtweisen z. T. etwas unterschiedlich sind: In den
von Dir beschriebenen Szenarios kommt anscheinend ein Großteil der Daten
aus (teilweise technisch unzulänglichen) externen Quellen. In unserem
Fall entstehen >95 Prozent der Daten inhouse und sind deshalb von Anfang
an technisch in Ordnung. Das dürfte auch erklären, warum wir bisher auf
automatisierte Kontrollwerkzeuge verzichten konnten, da wir die paar
wenigen Anzeigen, die von außen kommen, auch gut per Hand sichten
können. In Deinem Fall sieht ds natürlich anders aus.
> > Falls es Freisteller gegeben hat, müssten die ja bereits in diesem
> > Stadium der Produktion fertig gewesen sein wegen Textumfluß und so ...
>
> Für den Textfluß sind sie nicht nötig gewesen, da ja bereits in den
> angelieferten Xpress-Dateien entsprechende Polygonrahmen den Textfluß für
> Freisteller definierten.
Au weia ;-/
Das erinnert mich an Photoshop-Freisteller, die wir gelegentlich von
"professionellen" Agenturen erhalten, die anscheinend bis heute nicht
begriffen haben, dass Bezier-Kurven deshalb Bezier-KURVEN heissen, weil
man damit Kurven machen kann ;-)
> >> Das Kontrollkriterium für angelieferte Kundenbilder war wirklich einfach:
> >> Hat der Server ein Lay gemacht, war alles i.O.;
> >
> > Ist das wirklich ein zuverlässiges Kriterium?
>
> Ja.
Nein. Siehe folgende 72 dpi-Diskussion.
> > Angenommen, er kriegt ein PS3-EPS (gibt's eigentlich nicht, ich weiß ;-),
>
> Vor allem "damals" nicht.
>
> > macht davon ein .lay, weil das ja für ihn in Ordnung geht, und eines der
> > Ausgabegeräte (Belichter, Proof, sw-Drucker) kann nur PS Level 1. Was
> > passiert dann?
>
> Beim Aufziehen von "Workflows" sollte man derlei natürlich berücksichtigen,
> was für mich bedeutet, daß Level 1 Geräte einfach im internen Betrieb keinen
> Platz mehr haben (wohl aber bei Grobbildern, bei denen man durch gezielte
> Parametrisierung des Servers dafür sorgen kann, daß diese auch für externe
> Grafiker, die noch einen originalen Apple Laserwriter besitzen eine Level 1
> taugliche "printable Preview" beinhalten). Richtschnur war damals einfach PS
> Level 2.
Da stimme ich Dir zu, dass man heute zumindest PS-Level 2 voraussetzen
muss.
> Aber um auf die Frage zurückzukommen: Helios hat in den OPI-Server (aktuell
> richtigerweise ImageServer getauft) entsprechenden Support eingebaut, der
> beim Austausch von Dateien anhand der Queue-Konfiguration (d.h. PPD des
> Ausgabegeräts) den PS-Level ausliest und berücksichtigt. Bspw. werden
> JPEG-komprimierte EPS auf Level 1 Geräten dekomprimiert geschickt (da ja die
> ganzen Encode/Decode Filter erst mit PS Level 2 kamen), etc.
Ah gut, das wollte ich wissen.
> Wie weit das auch hinsichtlich einzelner Konstrukte im PS-Code geht,
> entzieht sich aber meiner Kenntnis, da ich -- wie schon betont -- Level 1
> Geräte seit Jahren deaktiviere, wenn sie mir in den Weg kommen (bringt wegen
> den ganzen Limitationen mehr Ärger als Nutzen)
> Ich müsste mal nachschauen, was momentan aktuell ist. Aber mit den letzten
> Versionen (in Helios-Sprech "CD 017" genannt) wurden in so einem Fall bspw.
> SmoothShades von PS 3 in CMYK Bildobjekte für Level 1 Interpreter gewandelt.
>
> Daß hierbei aber Kompromisse eingegangen werden müssten, die oftmals nicht
> wirklich sinnvoll realisierbar sind, ist natürlich klar.
Logisch.
> > Sozusagen rippen nach /dev/null nur um zu sehen, ob's läuft?
>
> Yo. Allerdings mit der endgültigen Belichterauflösung von 2540 dpi und dann
> runtergerechnet auf 300 dpi. Wie es der Zufall wollte, standen bei uns vor
> Ort und bei dem CtP-Dienstleister im Kurpfälzischen identische Delta-RIPs
> von Heidelberg.
Ok, bei identischen RIPs sollte man dann wirklich davon ausgehen können,
dass es klappt ;-)
> >> Sollten an Seiten nur Bildkorrekturen anfallen, so wurden die in der
> >> Retuscheabteilung gemacht; in diesen Fällen musste ich die Xpress-Seite
> >> nicht mehr anfassen, da ja sonst nichts Inhaltliches an der Seite geschehen
> >> ist. Es reichte völlig, die PS-Datei erneut über die OPI-Queue auf den
> >> Proofer zu schieben :-)
> >
> > Da hätte ich so meine Probleme damit, wenn die Daten mittendrin nicht
> > mehr konsistent sind, also die PS-Daten vom Inhalt der ursprünglichen
> > Quark-Datei abweichen. Auch, wenn's bloß die Bilder sind ...
>
> Ach weißt Du, ich habe bei Katalogproduktionen mit PDF-Handshake schon aus
> einer Variante eines Katalogs (A4 4c für Digitaldruck) nur durch Grob-/
> Feinbild-Austausch und Nachbearbeitung durch PitStop Server eine zweite (A5
> s/w für Rollenoffset) erzeugt.
[Anleitung für HELIOS-Server gesnippt]
>
> Wenn man den Vorgang begriffen hat und sich auf der Zunge zergehen hat
> lassen, was damit für Produktionsschmankerl möglich sind, dann zerstreuen
> sich derlei Bedenken, die meisten "aus dem Bauch heraus" kommen, erstaunlich
> schnell ;-)
Technisch sehr nett gelöst ;-)
Ich hätte es trotzdem anders gemacht: Quark-Dokument öffnen,
Belichter-Seitengröße auf DIN A 5, Skalierung 71%, Fraben als
Graustufen, drucken, fertig.
Das hätte zwar vermutlich den Rechner länger in Beschlag genommen als
Deine Variante, allerdings wäre ich nach 30 Sekunden fertig gewesen ;-)
Möglicher Nachteil (bei beiden Varianten): Keinen Einfluß auf Wiedergabe
der Graustufenbilder, da in beiden Fällen automatisch erstellt (Pitstop
Server vs. QXP).
> >> Du im layouts Ordner Grobbilder im PNG-Format mit 144 dpi erhältst, etc.
> >> (Hint: Alle, die sich von Photoshop Bilder "fürs Web" runterrechnen lassen
> >> sind irgendwie selbst schuld ;-)
> >
> > Da könntest Du jetzt aber auch mal eine Wette verlieren: Ich bin mir
> > sicher, dass ich mit _motivbezogener_ manueller Web-Optimierung bessere
> > Ergebnisse hinkriege als mit einem 08/15-Batch.
>
> Ich sprach nicht von besser sondern nur von unaufwändiger. Und ob die Leute
> nun einen Photoshop-Batch laufen lassen oder vorher nachdenken und am Server
> einen Ordner richtig benennen, dürfte in beiden Fällen nicht viel mit
> manueller Optimierung aber sehr wohl viel mit gesparter Zeit zu tun haben.
Bei uns würde solch ein Photoshop-Batch einfach über Nacht laufen, dazu
wäre also auch keine zusätzliche Manpower nötig. Aber kann ich durch
simples Benennen eines HELIOS-Ordners auch die gleichen umfangreichen
Parameter einstellen wie in einer PS-Aktion?
> BTW: In der neuen ImageServer Version ist auch ein Hotfolder-Mechanismus
> eingebaut, mit dem man -- entsprechende Kenntnis der Helios CLI-Tools
> vorausgesetzt -- verdammt mächtige Bildkonvertierungen direkt auf dem Server
> anstossen kann.
>
> > Gleiches gilt IMHO auch für Bildseparationen.
>
> Naja, jetzt streifen wir das Thema Farbmanagement und deren philosophische
> Randerscheinungen aber gewaltig ;-)
Da hast Du Recht, das würde hier wirklich zu weit führen ;-)
> Nur noch so viel: Ich habe gaudihalber mit LinoColor auch schon in LAB LH
> direkt auf den Server gescannt (und alle Bildoptimierungen im
> LCH-Arbeitsfarbraum direkt in LinoColor in den LabLH Bildern vorgenommen).
> Das waren für mich per Definition die farbrichtigen Originale. Und diese
> sind zu meiner vollsten Zufriedenheit während der Ausgabe vom Server
> anhand eines guten Zielprofils separiert worden.
So ist das auch völlig ok. Bilddaten im größtmöglichen Farbraum erfassen
und dann einsatzbedingt auf den entsprechenden Gammut stutzen. Full ACK.
> > BTW: Löscht Helios eigentlich automatisch die .lay-Dateien, wenn ich die
> > Feinbilder lösche? Wäre IMHO sinnvoll.
>
> Kommt halt drauf an. Genau dieses Feature (die Grobdaten eben nicht auf
> Gedeih und Verderb mit den Feindaten zu koppeln) macht für mich eine der
> grössten Stärken des Servers aus! Ohne diese Funktionalität sind nahezu alle
> erweiterten Workflows, die wirklich von den OPI-Funktionalitäten Gebrauch
> machen (also alles, was über "schneller spoolen" hinausgeht!) weitestgehend
> nutzlos.
Birgt das nicht irgendwo die Gefahr, dass Quark alle Bilder mit "OK"
bewertet, aber es dann bei der Ausgabe ein Desaster gibt, weil doch
einige HighRes-Daten fehlen? Wenn ich OPI richtig verstanden habe,
werden doch in QXP nur die .lay-Daten platziert, ohne dass QXP
überprüfen könnte, ob die Originale noch vorhanden sind.
> Was man dagegen machen kann, ist ein nächtlicher Cronjob, der nach
> Lay-Waisen sucht (das ist maximal ein Dreizeiler, da Helios einem einen
> ganzen Sack sehr effizienter CLI-Tools beipackt).
>
> Allerdings habe ich dieses Feature noch *nie* gebraucht, da ich halt
> Verfechter von klaren Ordnerstrukturen bin.
Das verstehe ich jetzt nich so ganz. Was haben klare Ordnerstrukturen
mit .lay-Waisen zu tun?
> > Bei Deiner Version verlasse ich mich _beim_ Layouten blindlings darauf,
> > dass die Bilder ok sind.
>
> Nein. Ich verlasse mich darauf, daß sie gewissen formalen Kriterien genügen,
> die die Ausgabe dieser Bilder sicherstellen (Farbräume, Bilder vom
> Dateiformat her okay, d.h. keine defekten Dateien). Das sagt nichts darüber
> aus, ob da Bilder evtl. nur 72 dpi haben (was sie oft hatten, da im Verlag
> manches mal auch Bilder direkt aus dem Web gezogen wurden) oder farblich
> völlig daneben sind, etc.
Ein Bild mit 72 dpi (immer bei 100% Skalierung, versteht sich) ist bei
einer hochauflösenden Druckausgabe immer irgendwie "defekt" ;-)
> > Und erst wenn bei der Ausgabe der Job in der Fehlerqueue landet,
>
> Wieso sollte er da landen? Sicher nicht wegen 72 dpi, denn das prüfe ich
> nicht.
Warum? Genau das ist doch ein KO-Kriterium für die Ausgabe, das ich eben
nicht erst im Proof, auf den Filmen oder schlimmstenfalls im fertigen
Druckerzeugnis entdecken möchte.
> > kriege ich mit, dass ein Bild z. B. nur 72 dpi hatte und ich deshalb mein
> > Layout (falls das Bild in keiner anderen Auflösung verfügbar ist) über den
> > Haufen werfen muss.
>
> 72 dpi bedeutet doch erstmal gar nichts. Wenn ich so ein Bildchen auf 20%
> skaliere, erhält es eine effektive Auflösung von 360 dpi und ist damit mehr
> als ausreichend für Offsetdruck (sogar 80er Raster).
Sorry, ich hätte wohl dazuschreiben sollen, dass sich das natürlich auf
die endgültige Auflösung inklusive Skalierung bezieht. Ich hatte das
wohl einfach mal vorausgesetzt ;-)
> Es kommt eben immer auf den Einsatzzweck des Bildes an. Wenn so ein Bild
> partout als Aufmacher mit 100% eingebaut werden soll, dann fällt das
> allerspätestens auf dem Proof auf, daß das nicht der Weisheit letzter
> Schluss ist.
Aber eben erst auf dem Proof. IMHO ist das bereits zu spät, da dann ja
bereits unnötige Kosten entstanden sind. Auch wenn's _nur_ ein Proof
ist.
> > Oder habe ich was übersehen?
>
> Glaub schon, bzw. kam anscheinend nicht klar genug rüber, daß die Seiten
> schon fertig layoutet vom Verlag kamen.
>
> Als ich das Magazin übernommen hatte, bin ich relativ bald zum Verlag
> gefahren um ein bisserl Smalltalk abzusetzen und den Vorschlag anzubringen,
> eine halbtägige Schulung (kostenlos) für die Grafiker zu machen (denn was
> die teilweise ablieferten kannte ich schon von vorher als Oberdatenklempner
> des Betriebs). Das hat sich insgesamt für beide Seiten gelohnt, da dort dann
> manche Zusammenhänge bspw. hinsichtlich Bildauflösung <--> Platzierung im
> Layout oder Farbräumen und den Gefahren verlustbehafteter Bildkompression,
> etc. klarer wurden und sie eher bereit waren, auf Kompetenzgerangel zu
> verzichten und kritische Bilder (bzw. deren Retusche und Optimierung) von
> vorneherein der Obhut des "freundlichen Dienstleisters" zu überlassen.
Sowas lohnt sich im Regelfall für beide Seiten und hilft, später Ärger,
Stress und Schuldzuweisungen zu vermeiden. Es geht doch nichts über klar
definierte Mensch-Mensch-Schnittstellen [1] ;-)
> Naja, der direkte PDF-Export hat es halt in sich (weil so nah dran am
> PDF-Standard, daß man merkt, daß es leider kein Ausgabegerät gibt, das da
> noch mithalten kann). Aber wenn man ein PS3-RIP unterm Tisch stehen hat
> (<hüstel>) dann ist das doch alles kein Problem, oder?
Ist das wirklich so einfach? Wir haben insgesamt drei PS 3-RIPs (Viper,
Torrent und Epson Laserdrucker), aber keines davon kommt mit PDF-Dateien
ordentlich klar. Einige wenige PDFs laufen, aber die meisten nicht. Erst
ein Rückwandeln in PS mittels Acrobat funktioniert eigentlich immer
reibungslos.
> > sich fragend, ob bei Sehnenscheidenentzündung in beiden Unterarmen
> > bereits Frührente beantragt werden könnte ;-)
>
> Ach, hast Du damit Probleme?
Nö, aber wenn ich weiter so viel tippen muss ;-)
Ciao
Achim
[1] F'up nach dtl? ;-)))
Thomas Kaiser
> Ich finde es nur sehr schade, dass immer mehr Software-Hersteller dazu
> übergehen, solche "Undocumented Features" einzubauen.
Naja, das ist nicht wirklich undokumentiert. Andersrum gefragt:
Wieviel Prozent Doku (Handbuch, Tech-Infos, online Knowledge-Base,
Update Infos, etc.) liest Du zu einer Software? Mehr als 0,1% oder
eher nicht? ;-)
> Sowas gehört für mich auf jeden Fall ins Handbuch. Wo sind diese "internen"
> Distiller-Parameter eigentlich beschrieben?
Auf Seite 35 in der Beschreibung der Distiller-Parameter natürlich:
<http://partners.adobe.com/asn/developer/acrosdk/docs.html>
Generell interessant:
<http://partners.adobe.com/asn/developer/technotes/main.html>
Gruss,
Thomas
Achim Denzl
> > Ich finde es nur sehr schade, dass immer mehr Software-Hersteller dazu
> > übergehen, solche "Undocumented Features" einzubauen.
>
> Naja, das ist nicht wirklich undokumentiert. Andersrum gefragt:
> Wieviel Prozent Doku (Handbuch, Tech-Infos, online Knowledge-Base,
> Update Infos, etc.) liest Du zu einer Software? Mehr als 0,1% oder
> eher nicht? ;-)
Früher habe ich fast alle Handbücher gelesen, mittlerweile fehlt mir
leider oft die Zeit dazu, was irgendwie schade ist, weil einem dann
vielleicht doch das eine oder andere entgeht ;-)
>
> > Sowas gehört für mich auf jeden Fall ins Handbuch. Wo sind diese "internen"
> > Distiller-Parameter eigentlich beschrieben?
>
> Auf Seite 35 in der Beschreibung der Distiller-Parameter natürlich:
>
> <http://partners.adobe.com/asn/developer/acrosdk/docs.html>
Gut, aber das sind TechNotes. Ich meinte, das gehört in das "normale"
Enduser-Handbuch..
> Generell interessant:
>
> <http://partners.adobe.com/asn/developer/technotes/main.html>
Danke für die Links, sind beide sehr vielversprechend ;-)
Achim Denzl
> Wieso? Den Textfluß mit Poligonrahmen einzustellen (gut, wenn du
> unbedingt willst, kannst du in QXP4 auch Kurven hinfummeln -- ist aber
> kontraproduktiv) ist das übliche und einzig sinnvolle Verfahren in
> der Situation.
Finde ich nicht. Schließlich habe ich ja bereits in Photoshop einen
sauberen Beschneidungspfad erstellt, und der stellt IMHO die beste
Grundlage für den Textumfluß dar.
Ciao
Achim
Achim Denzl
> > Finde ich nicht. Schließlich habe ich ja bereits in Photoshop einen
> > sauberen Beschneidungspfad erstellt, und der stellt IMHO die beste
> > Grundlage für den Textumfluß dar.
>
> Im Rohscan? Ich befürchte, wir reden aneinander vorbei.
Vielleicht. Meiner Meinung nach ist aber trotzdem ein _ordentlicher_
Textumfluß nur mit einem Kurven-Pfad möglich, wobei ein Photoshop-Pfad
im Regelfall präziser zu erstellen ist als ein Pfad in QXP. Das Problem
bei den Polygon-Konstrukten (die wir - zugegeben - in Ausnahmefällen
auch verwenden) ist, dass sich der Textumbruch erneut ändert, wenn ich
zu einem späteren Zeitpunkt das Polgon durch den richtigen Pfad ersetze.
Für die layouterische Spiel- und Bastelphase wäre es aber in der Tat
unsinnig, jedes in Frage kommende Bild erst penibel freizustellen. Da
tut's dann wirklich auch ein Polygon ;-)
Cioa
Thomas Kaiser
<news:1fpo6wn.14kfawp1f0l5j4N%use...@dtpd.com>:
>>> Wo sind diese "internen" Distiller-Parameter eigentlich beschrieben?
>>
>> Auf Seite 35 in der Beschreibung der Distiller-Parameter natürlich:
>
> Gut, aber das sind TechNotes.
Ja. Mit einigen tausend Seiten zusammengenommen...
> Ich meinte, das gehört in das "normale" Enduser-Handbuch..
Also in dieses Ding, das niemand liest, oder? Und was bringt das dann?
Oder mal wieder andersrum: Es stehen in manchen Handbüchern so viele
wertvolle Sachen drin, von denen aber nirgends Gebrauch gemacht wird.
Viele Schulungen könnte man sich schenken, wenn die Leute einfach Doku lesen
würden (schon klar; es gibt verschiedene Lern-Typen, die auf verschiedene
"Medien" unterschiedlich ansprechen). Meistens ist es die Scheu oder die
fehlende Zeit, die zwischen einem selbst und den Informationen stehen.
Wenn man bedenkt, wieviel Zeit und Aufwand man dadurch sinnlos vergeudet,
dann sehen Schulungskosten oder die Tagessätze von Consultants doch oftmals
auf einmal ganz anders aus...
Gruss,
Thomas
Thomas Kaiser
<news:1fpocqu.1m0y8g51o7j2teN%use...@dtpd.com>:
> Das Problem bei den Polygon-Konstrukten (die wir - zugegeben - in
> Ausnahmefällen auch verwenden) ist, dass sich der Textumbruch erneut
> ändert, wenn ich zu einem späteren Zeitpunkt das Polgon durch den richtigen
> Pfad ersetze.
Und warum machst Du das? Wieso willst Du überhaupt die Grundlageumfluss
mittendrin ändern? Das macht doch überhaupt keinen Sinn!
Selbst wenn ich initial einen Freistellpfad vorgesetzt bekommen sollte, habe
ich oftmals den Rahmen dupliziert und den Textfluß mittels starrem Polygonen
"festgezurrt", damit eben später nichts mehr passieren konnte.
Daß einem eine kleine Korrektur an einem Freisteller seitenweise das Layout
über den Haufen werfen kann finde ich nicht mehr tolerabel.
Insofern haben wir damals auch auf Grafiker eingewirkt, daß sie im Fall von
Freistellern bei sich eben nicht irgendwelche Layoutscans freistellen und
diese dann umfließen lassen, weil spätestens beim Highend Scan der viel
exaktere Freisteller, der dann den Umfluß definiert, ihnen alles über den
Haufen wirft.
Gruss,
Thomas
Thomas Kaiser
<news:1fphs11.1izww4vu23sfyN%pa...@stud.uni-frankfurt.de>:
> Wirklich Cobra?
So hieß AFAIR das UNIX-basierte Software-RIP von AGFA (wenn's schon Viper
nicht war)
> Ich kenne einige die Corba mit Cobra verwechseln, wobei Corba nicht auf
> Solaris beschränkt ist.
Reden wir jetzt von Cobra (Giftschlange) vs. Corba (Common Object Request
Broker Architecture)? ;-)
Gruss,
Thomas
Achim Denzl
> > Das Problem bei den Polygon-Konstrukten (die wir - zugegeben - in
> > Ausnahmefällen auch verwenden) ist, dass sich der Textumbruch erneut
> > ändert, wenn ich zu einem späteren Zeitpunkt das Polgon durch den richtigen
> > Pfad ersetze.
>
> Und warum machst Du das? Wieso willst Du überhaupt die Grundlageumfluss
> mittendrin ändern? Das macht doch überhaupt keinen Sinn!
Eben. Aber vielleicht liegt auch da das Problem eher an den
unterschiedlichen Aufgabenstellungen. Wir sind eine Setzerei, keine
Kreativagentur, die sich durch Dutzende von Varianten kämpfen muss. Wenn
wir zu arbeiten beginnen, steht bereits fest, welches Bild wohin soll.
Und dann werden zuerst die Freisteller gemacht und diese danach mit
bereits endgültigem Pfad im Layout verwendet. Farbkorrekturen und
Retuschen kommen dann unter Umständen erst später, aber die ändern ja
den Pfad und damit den Textumbruch nicht mehr.
> Selbst wenn ich initial einen Freistellpfad vorgesetzt bekommen sollte, habe
> ich oftmals den Rahmen dupliziert und den Textfluß mittels starrem Polygonen
> "festgezurrt", damit eben später nichts mehr passieren konnte.
Nur wenn Du dann das Bild veränderst (Platzierung, Skalierung), stimmt
Textfluß und Bildkontur nicht mehr überein ;-(
> Daß einem eine kleine Korrektur an einem Freisteller seitenweise das Layout
> über den Haufen werfen kann finde ich nicht mehr tolerabel.
Kommt immer auf den Anspruch an. Wir legen Wert auf _exakten_
Textumfluß, insbesondere bei großen, filigranen Freistellern mit wenigen
geraden Kanten. Und da versagt die Polygon-Methode völlig; zumindet der
Aufwand wäre deutlich höher, einen solchen Freisteller nochmals mit
Polygonen nachzubauen ...
> Insofern haben wir damals auch auf Grafiker eingewirkt, daß sie im Fall von
> Freistellern bei sich eben nicht irgendwelche Layoutscans freistellen und
> diese dann umfließen lassen, weil spätestens beim Highend Scan der viel
> exaktere Freisteller, der dann den Umfluß definiert, ihnen alles über den
> Haufen wirft.
Vielleicht können wir uns ja darauf einigen:
Layout-Jobs mit unbearbeitetem Bildmaterial:
Textumfluss mittels "Quick'n'Dirty" Polygon-Rahmen
Reinzeichnungen mit bearbeitetem Bildmaterial:
Textumfluss mittels exaktem Pfad-Freisteller
Was hältst Du davon?
Ciao
Thomas Kaiser
<news:1fpmftp.40cualwacaaaN%use...@dtpd.com>:
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> Ich fand die Diskrepanz zwischen Marketingversprechen und Realität mal
>> wieder erschreckend (wie leider schon zu oft bei AGFA)
>
> Ich glaube, da stehen sich die "Großen" gegenseitig in Nichts nach ...
Ich habe zumindest von den Heigelbergern (bzw. früher eben Linotyplern) noch
nie Blödsinn verzapft bekommen. Aber anscheinend stach die Münchner
Niederlassung von denen in Punkto Qualität auch ziemlich hervor... Insofern
verallgemeinere ich mal lieber nicht...
> In den von Dir beschriebenen Szenarios kommt anscheinend ein Großteil der
> Daten aus (teilweise technisch unzulänglichen) externen Quellen.
Kein Großteil sondern ein bestimmter Teil (bei dem Magazin ca. 30% der zu
platzierenden Abbildungen -- die Kleinanzeigenseiten *nicht* mitgerechnet)
Dieser Prozentsatz ist aber auch der, der "es in sich hat", d.h. der
potentiell fehlerträchtig war. Denn das, was im Haus dann noch produziert
wurde, waren im wesentlichen eben Scans, die auszuretuschieren und partiell
eben freizustellen waren.
> In unserem Fall entstehen >95 Prozent der Daten inhouse und sind deshalb
> von Anfang an technisch in Ordnung.
Aha. Und ihr übernehmt in all den Fällen auch niemals Fremddaten? Immer
"from scratch"? Nie ein Bild im falschen Farbraum in ein selbst erstelltes
EPS gebastelt? ,-)
> Das dürfte auch erklären, warum wir bisher auf automatisierte
> Kontrollwerkzeuge verzichten konnten, da wir die paar wenigen Anzeigen, die
> von außen kommen, auch gut per Hand sichten können. In Deinem Fall sieht ds
> natürlich anders aus.
Ja, wobei ich "hausintern" für kein geeignetes Kriterium halte (vielleicht
in Betrieben mit weniger als 5 Leuten noch?)
[Polygonrahmen definieren Textfluß für Freisteller]
> Das erinnert mich an Photoshop-Freisteller, die wir gelegentlich von
> "professionellen" Agenturen erhalten, die anscheinend bis heute nicht
> begriffen haben, dass Bezier-Kurven deshalb Bezier-KURVEN heissen, weil
> man damit Kurven machen kann ;-)
Vorsicht, gell! ;-)
Das ist nicht wirklich zu vergleichen, da das eine der Textumfluß ist
(den man als Typograph IMO sowieso nicht einfach so an einem Pfad entlang
ausrichten kann, weil die nötigen Algorithmen die "Grauwerte" mancher
Buchstabenteile nicht angemessen berücksichtigen!) und das andere die
Definition des Freistellers selbst.
Ich habe es bspw. *immer* wenn kein Pfadfreisteller nötig war (weil bspw.
Personen einfach vor einen weissen Hintergrund gestellt werden mussten) so
gehalten, daß ich den Freisteller "weich" erstellt habe (bisserl mit Pfad
vorgezeichnet und dann ab in Maskierungsmodus und mit Pinsel und Radiergummi
und Gaußschem Weichzeichner verkünstelt) und anschl. durch Umwandlung von
Auswahl zu Pfad einen groben Pfadfreisteller mit mehreren Pixeln Abstand zur
eigentlichen Freistellerkontur drumherumgelegt habe (damit die Grafiker in
der Layoutphase zügig arbeiten können)
>>> Sozusagen rippen nach /dev/null nur um zu sehen, ob's läuft?
>>
>> Yo. Allerdings mit der endgültigen Belichterauflösung von 2540 dpi und dann
>> runtergerechnet auf 300 dpi. Wie es der Zufall wollte, standen bei uns vor
>> Ort und bei dem CtP-Dienstleister im Kurpfälzischen identische Delta-RIPs
>> von Heidelberg.
>
> Ok, bei identischen RIPs sollte man dann wirklich davon ausgehen können,
> dass es klappt ;-)
Sie müssen nicht unbedingt identisch sein aber ähnliche Eigenschaften
aufweisen. So kannst Du bspw. mit dem Interpreter eines Laserdruckers (der
mit bspw. 600 dpi rippt) niemals Probleme simulieren, die durch "Flatness"
Probleme erst später in der Kette passieren können.
Oder Positionierungsgeschichten, die sich bei 600 dpi nicht bemerkbar machen
aber dann bei 2400 oder 2540 dpi.
Ich bin damals einige Male mit dem Ansatz, bei niedriger Auflösung zu
rippen, auf die Nase gefallen und habe dann wenigstens das RIP an sich in
der entsprechend hohen Auflösung laufen lassen, um wirklich eine sinnvolle
Simulation des Ausgabeergebnisses zu bekommen.
[Beschreibung, wie man aus einem A4-Katalog parallel auch eine partiell
*andere* A5-Variante erstellen kann ohne zwei Korrektur-/Freigabezyklen]
> Technisch sehr nett gelöst ;-)
Ich glaube, Du hast eine relevante Information überlesen, nämlich, daß es
nicht ein und derselbe Katalog war. Die farbige A4-Variante hatte andere
Hintergrundabbildungen auf jeder Seite (leicht wolkige Abbildungen, die im
s/w Offset nur nach mangelhaftem Druckergebnis ausgesehen hätten), hatte zum
Teil andere Logoabbildungen (die feinere Variante, die in A5 durch
einfacherer Grafiken ersetzt werden musste, weil die hellen Linien sonst
zugesoffen wären) und noch ein paar Kleinigkeiten.
Es handelte sich um zwei verschiedene Kataloge, die nur Produkttexte und
Produktabbildungen gemein hatten, also bei manueller Arbeitsweise sich in
folgendem Aufwand unterschieden hätten:
- 2500 mal drei verschiedene EPS je Seite laden
- 2500 mal in insg. 4 Textboxen je Seite Textänderungen durchführen
Hätte alleine für das Erstellen der beiden Katalogvarianten insg. 5 Leute
ca. 2-3 Wochen mit sattem Überstundenaufkommen und durchgearbeiteten
Wochenenden beschäftigt (das waren zumindest die Erfahrungswerte, bevor ich
dort in dem Laden "Database Publishing für Arme" per PDF-Handshake und
AppleScript implementiert hatte -- danach sank die Zeit für das Erstellen
auf die für die Umwandlung einer Excel-Datei in eine tabseparierte Textdatei
und das Aufrufen eines Skripts nötige, *wenn* keine Probleme auftraten, was
natürlich nie vorkam ;-)
> Ich hätte es trotzdem anders gemacht: Quark-Dokument öffnen,
Es wären 2.500 Dateien gewesen, die Du zweimal hättest anfassen müssen.
Außerdem hättest Du bei der Summe an Eingriffen je Seite in jedem Fall zwei
separate Korrekturläufe je Katalogvariante machen müssen (und es wären den
Korrekturlesern mehr Fehler durchgerutscht, weil sie jede Seite zweimal
hätten lesen müssen)
> Belichter-Seitengröße auf DIN A 5, Skalierung 71%,
Wäre zuwenig gewesen, da die Anforderungen für den A4-Katalog hinsichtlich
Unterschied brutto/netto Seitenformat ziemlich unterschiedlich gewesen sind.
Wir konnte uns soweiso nur durch einen Trick mit PDFMarks und Manipulieren
der TrimBox respektive Crop-/Mediabox retten (weil der Rollenoffsetdrucker
in der 71% Variante unbedingt 4 mm Beschnittzugabe wollte aber die 4c
Druckerei keinesfalls mehr als 3 mm (in 100%) verkraftet hat, da sie sonst
Mehraufwand bzgl. Druckvorbereitung hätten) --> PDF und die Magie der Boxen
sind was Feines :-)
Das war auch das Pilotprojekt für ein Ansinnen des Kunden, allen seinen über
30 verschiedenen Druckereien identische und für alle verarbeitbare PDFs zur
Verfügung stellen zu können, damit die Druckereien eben nicht bei
Preisverhandlungen die Daumenschrauben ansetzen können, wenn sie wussten,
daß die PDFs bereits auf Gedeih und Verderb auf ihren spezifischen
Bogenmontage-/Belichtungsworkflow angepasst waren.
Der Katalogkunde konnte somit bis kurz vor und sogar nach Druckbeginn noch
beliebig die Druckerei wechseln (Mann, war das ein Rumgeeier damals, da
natürlich *jede* der Druckereien vorher darauf bestanden hat, daß nur ihre
eigenen Datenanlieferungsrichtlinien, die sich natürlich von allen anderen
unterschieden, zur korrekten Weiterverarbeitung führen können)
> Fraben als Graustufen,
Waren alles JPEG-komprimierte EPS (weil das exakt die Daten sind, die in
einer Bilddatenbank stets aktuell weltweit für den Kunden im Zugriff sind)
-- da kannst Du in XPress einstellen, was Du willst, es kommt nicht das
raus, was Du willst. Wieder einer der Punkte, an dem einem OPI-Server das
Leben erleichtern...
> drucken, fertig.
Ich halte Dir jetzt mal zugute, daß Du den wahren Aufwand nicht abschätzen
konntest anhand meiner bisherigen vagen Beschreibung ;-)
> Das hätte zwar vermutlich den Rechner länger in Beschlag genommen als
> Deine Variante, allerdings wäre ich nach 30 Sekunden fertig gewesen ;-)
Schon mal 2.500 leere Seiten aus Xpress am Stück zu drucken versucht? Wohl
eher nein, oder? Denn selbst das geht nicht in 30 Sekunden (zumindest nicht
am Mac mit den mir bekannten Rechnern). Abgesehen davon, daß bei mehr als
1000 Seiten am Stück die ulkigsten Dinge passieren (Absturz Xpress bis hin
zu kompletten Lockups des Macs)
Ich würde Deinen Aufwand bei manueller Vorgehensweise auf diverse Wochen
schätzen. Und dabei ist noch nicht die Korrekturphase eingerechnet, die
natürlich doppelt so aufwändig ist als wenn man nur eine neutralisierte
Version des Katalogs bearbeitet und den Rest durch OPI erledigen lässt.
> Möglicher Nachteil (bei beiden Varianten): Keinen Einfluß auf Wiedergabe
> der Graustufenbilder, da in beiden Fällen automatisch erstellt (Pitstop
> Server vs. QXP).
Die Umwandlung war durch Profil recht simpel möglich, da das alles
technische Motive waren (da kann man die Farben prima verbiegen vorher,
damit anschl. kontrastreiche s/w Abbildungen bekommt). Das wäre dann wieder
die Colormanagement-Komponente des OPI-Servers gewesen :-)
> kann ich durch simples Benennen eines HELIOS-Ordners auch die gleichen
> umfangreichen Parameter einstellen wie in einer PS-Aktion?
Nein, wie denn auch? Die Parameter, die Du einem Ordner durch Benennung
mitgeben kannst, sind sehr endlich (konkret abgesehen von Farbraum,
Dateiformat und Auflösung sowieso keine).
Was anderes ist, wenn Du mal die kleinen CLI-Tools 'layout', 'oiimginfo',
'psresolve' einsetzt. Man kann damit (und dem neuen scriptsrv im aktuellen
ImageServer) recht mächtige Hotfolder einrichten, die anhand der Benennung
des Ordners lernen, was sie zu tun haben, bspw. könnte ein Ordner
144_RGB_600_800_+.png
in den Du ein CMYK und ein RGB-Profil reinwirfst dafür sorgen, daß alle
hineingeschobenen Bilddateien auf 600x800 Pixel (bei Beibehaltung des aspect
ratio und automatischer Skalierung auf den passenden x- oder y-Wert) als PNG
(unter Berücksichtigung evtl. in den Bildern enthaltener Freisteller) mit
144 dpi abgespeichert werden.
Der Phantasie sind dabei kaum Grenzen gesetzt, eher der auch für normale
Bennutzer noch nachvollziehbaren Flexibilität hinsichtlich
Ordnerparametrisierung.
BTW: Mit einem der neuen HELIOS Updates von letzter Woche können jetzt mit
dem 'layout' Tool auch Previews von Xpress-Dateien (und demnächst
anscheinend auch InDesign) direkt auf dem Server extrahiert und umgebaut
werden. Ich habe das bei einem Kunden jetzt bereits so laufen, daß von allen
Xpress-Dokumenten, die sich ändern immer gleich die entsprechenden
Vorschauen (bei Bedarf als Doppelseitenansicht zusammengebaut) als PDF in
eine Datenbank geschoben werden. Es ist nur nötig, [Apfel][S] zu drücken,
der Rest geschieht unauffällig im Hintergrund und für niemanden umgehbar
(bzw. zu vergessen; das war das eigentliche Ziel der Aktion, unvermeidabre
menschliche Nachlässigkeiten zu verunmöglichen)
>> [...]
>> dieses Feature (die Grobdaten eben nicht auf Gedeih und Verderb mit den
>> Feindaten zu koppeln) macht für mich eine der grössten Stärken des Servers
>> aus! Ohne diese Funktionalität sind nahezu alle erweiterten Workflows, die
>> wirklich von den OPI-Funktionalitäten Gebrauch machen (also alles, was über
>> "schneller spoolen" hinausgeht!) weitestgehend nutzlos.
>
> Birgt das nicht irgendwo die Gefahr, dass Quark alle Bilder mit "OK" bewertet,
> aber es dann bei der Ausgabe ein Desaster gibt, weil doch einige HighRes-Daten
> fehlen?
Nenne es nicht Desaster sondern angepeilter Einsatzzweck ;-)
In dem länglichen Beispiel, daß ich letztens postete, benutzte ich genau
das, um sicherzustellen, daß auch alle hausintern entstandenen Scans
*definitiv* den Arbeitsplatz eines Retuscheurs gestreift haben.
> Wenn ich OPI richtig verstanden habe, werden doch in QXP nur die .lay-Daten
> platziert, ohne dass QXP überprüfen könnte, ob die Originale noch vorhanden
> sind.
Ja. Das ist mitunter einer der Grundgedanken hinter OPI. Du kannst die
Grobdaten jemandem zum Layouten geben und diese enthalten nur eine Referenz
auf die Feinbilder (nach bspw. absolutem Pfad, parallel File-ID und können
bei Bedarf durch erweiterte Methoden wie bspw. der manuellen Zuordnung von
Suchpfaden verfeinert werden). Layoutet werden kann also völlig unabhängig
von der Verfügbarkeit der Feindaten.
Wenn dann der Grob-/Feinbildaustausch ansteht, müssen die Feindaten
natürlich im Zugriff sein, was normalerweise bei klaren Auftrags-/Ordner-
und Zuständigkeitsstrukturen kein Problem darstellt.
>> Was man dagegen machen kann, ist ein nächtlicher Cronjob, der nach
>> Lay-Waisen sucht (das ist maximal ein Dreizeiler, da Helios einem einen
>> ganzen Sack sehr effizienter CLI-Tools beipackt).
>>
>> Allerdings habe ich dieses Feature noch *nie* gebraucht, da ich halt
>> Verfechter von klaren Ordnerstrukturen bin.
>
> Das verstehe ich jetzt nich so ganz. Was haben klare Ordnerstrukturen
> mit .lay-Waisen zu tun?
Wie können denn verwaiste Grobbilder auf einem Server entstehen? Indem ich
die Feinbilder irgendwohin auslagere (denn wenn ich sie nur verschiebe, dann
können sie ja noch anhand der File-ID gefunden werden). Nur warum sollte
mich dieser Vorgang überraschen? Entweder es ist Absicht, daß die Feindaten
grad auf Tape-Library ausgelagert sind (und der Disponent in der
Sachbearbeitung das Wiedereinlagern an den Ursprungsort jederzeit wieder
triggern kann) oder die Feindaten stehen nicht im Zugriff, weil sie bspw.
gerade vom Kunden als _veraltet_ definiert wurden und deshalb nicht mehr
benutzt werden *dürfen*.
Also alles sehr bewusst herbeigeführte Zustände, bei denen es einen Grund
hat, wenn das Feinbild nicht dort ist, wo das Grobbild es erwartet. Aber
nicht das Chaos, das anscheinend bei manchen Betrieben dafür sorgt, daß die
Leute OPI als Last empfinden (wenn sie planlos Aufträge zwischen immer
überfüllten Server-Volumes hin- und herschieben und nicht kapiert haben, daß
sie sich in solchen Momenten das Leben mehr als unnötig erschweren)
Bei klaren Strukturen und einer passenden technischen Infrastruktur kann es
per Definition gar keine Lay-Leichen geben, da es immer einen Sinn hat, wenn
das Feinbild mal nicht im Zugriff ist.
> Ein Bild mit 72 dpi (immer bei 100% Skalierung, versteht sich) ist bei
> einer hochauflösenden Druckausgabe immer irgendwie "defekt" ;-)
Oder Stilmittel ;-)
Nee, im Ernst: Es hängt eben von der Skalierung in der Layoutanwendung ab,
ob 72 dpi als gut oder böse zu bewerten sind. Nur kann ich das ja auch nur
überprüfen, wenn ich einerseits Bildauflösung und andererseits Skalierung im
Programm gleichzeitig betrachte und dabei die effektive Auflösung im
fertigen Druckerzeugnis ermittele (was -- wenn man Photoshop benutzt --
sowieso schwer fällt, da Photoshop manches mal nicht die Auflösung aus den
eigentlich dafür vorgesehenen Metadatenfeldern in Bilddateien ausliest
(bspw. die entsprechenden JPEG-Marker bei JFIF) sondern seine eigenen
proprietären in den "Adobe Resource Blocks" benutzt und wenn diese fehlen
einfach dreist behauptet, 72 dpi vor sich zu haben!)
>>> Und erst wenn bei der Ausgabe der Job in der Fehlerqueue landet,
>>
>> Wieso sollte er da landen? Sicher nicht wegen 72 dpi, denn das prüfe ich
>> nicht.
>
> Warum?
Einerseits die Notwendigkeit, die effiziente Auflösung zu überprüfen (was
ich automatisiert nur über Werkzeuge wie bspw. PitStop Server resultierend
aus dem Druckjob an sich kann) und andererseits, weil es sich um ein
Stilmittel handeln könnte.
> Genau das ist doch ein KO-Kriterium für die Ausgabe, das ich eben
> nicht erst im Proof, auf den Filmen oder schlimmstenfalls im fertigen
> Druckerzeugnis entdecken möchte.
Naja, wozu gibt es einerseits ein Proof (das ja in dem von mir beschriebenen
Workflow soz. Pflichtprogramm ist) und andererseits sinnvolle Prüfkriterien,
die man ebenfalls mit einsetzen kann, wie bspw. PitStop Server (das ich in
der ursprünglichen Situation allerdings nicht einsetzen durfte)
Zurück zum Kern des Problems: Ich behaupte, es bringt nichts, die
Bildauflösung an sich zu prüfen, weil diese ohne das Wissen um den
Skalierungsfaktor im Layout schlichtweg gar nichts aussagt. Eine Überprüfung
muss also entweder in der Layoutanwendung geschehen (dafür hatte ich sogar
mal ein AppleScript geschrieben, das genau das für XPress-Dateien macht,
indem es die Auflösung der zu den platzierten Grobbildern gehörenden
Feinbilder mit dem Skalierungsfaktor in Verbindung setzte und bei
Unterschreiten gewisser Parameter Meldung machte) oder aber als elementarer
Bestandteil eines automatisierten Prüfmechanismus (once again: PitStop ist
praktisch)
> ich hätte wohl dazuschreiben sollen, dass sich das natürlich auf die
> endgültige Auflösung inklusive Skalierung bezieht. Ich hatte das wohl
> einfach mal vorausgesetzt ;-)
Aber genau diese Information fehlt (mir wenigstens) erstmal, wenn ich das
Bild so an sich anfasse...
>> Es kommt eben immer auf den Einsatzzweck des Bildes an. Wenn so ein Bild
>> partout als Aufmacher mit 100% eingebaut werden soll, dann fällt das
>> allerspätestens auf dem Proof auf, daß das nicht der Weisheit letzter
>> Schluss ist.
>
> Aber eben erst auf dem Proof. IMHO ist das bereits zu spät, da dann ja
> bereits unnötige Kosten entstanden sind. Auch wenn's _nur_ ein Proof
> ist.
Ja, aber da kommt es eben auf das an, was mit dem Kunden vereinbart ist und
wie sehr er gewillt ist, selbst Verantwortung für seine angelieferten Daten
zu übernehmen. Will er das nicht, dann werden die Serverqueues eben so
verkettet, daß zuerst der PitStop Server Durchlauf erfolgt und nur nach
erfolgreichem Aussortieren in den "OK" Ordner der zwischenzeitlich geparkte
Druckjob weiter auf's Proof durchgereicht wird.
BTW: Das A&O beim Aufspannen solcher Workflows ist übrigens die ausführliche
Dokumentation des Ganzen. Sonst sind die Leute binnen kürzester Zeit reif
für die Klapse :-)
>> Naja, der direkte PDF-Export hat es halt in sich (weil so nah dran am
>> PDF-Standard, daß man merkt, daß es leider kein Ausgabegerät gibt, das da
>> noch mithalten kann). Aber wenn man ein PS3-RIP unterm Tisch stehen hat
>> (<hüstel>) dann ist das doch alles kein Problem, oder?
>
> Ist das wirklich so einfach? Wir haben insgesamt drei PS 3-RIPs (Viper,
> Torrent und Epson Laserdrucker), aber keines davon kommt mit PDF-Dateien
> ordentlich klar.
Ein "PS 3 RIP" ist keine hinreichende Voraussetzung für direkte PDF-Ausgabe
(es braucht bei original Adobe Interpretern mindestens 3011.106 und das
Torrent sollte Scriptworks 5.3 oder höher beinhalten; bzgl. des Epson fehlt
mir der Name des RIPs um sinnvollen Senf abgeben zu können). Schick mal das
Folgende als PS-File auf die RIPs und guck nach:
%!PS
/Courier findfont 10 scalefont setfont
50 60 moveto
version cvr 200.000 ge {
(Interpreter: ) show product show
50 100 moveto
(PS-Level: ) show languagelevel 1 string cvs show
50 80 moveto
(Version: ) show version show
}
{ (PS-Level: 1 Version: ) show version show
} ifelse
showpage
> Einige wenige PDFs laufen, aber die meisten nicht.
Kann es sein, daß Du die Diskrepanz zwischen Marketing und Realität
kennengelernt hast? ;-))
Die meisten RIP-Hersteller erblödeten sich schon vor mehr als 5 Jahren, von
PDF-tauglichen RIPs zu fabulieren, derweil ist das erst seit ca. einem Jahr
(zumindest wenn man PDF 1.3 voraussetzt, was ich einfach mal tue) der Fall
und auch nur, wenn man brav seine Interpreter-Version raufsetzt.
> Erst ein Rückwandeln in PS mittels Acrobat funktioniert eigentlich immer
> reibungslos.
Yo. Und das ist aus mehreren Gründen oftmals nicht der falscheste Weg (bspw.
Konflikte mit Schriftnamen zwischen Dokument und Interpreter-residetnen
Schriften ausgeschlossen, sauberere Parametrisierung der InRIP Separation,
etc. --> Crackerjack oder PDF Output Pro können übers Jahr gesehen diverse
Quadratkilometer Film sparen)
Gruss,
Thomas
Achim Denzl
> >> Ich fand die Diskrepanz zwischen Marketingversprechen und Realität mal
> >> wieder erschreckend (wie leider schon zu oft bei AGFA)
> >
> > Ich glaube, da stehen sich die "Großen" gegenseitig in Nichts nach ...
>
> Ich habe zumindest von den Heigelbergern (bzw. früher eben Linotyplern) noch
> nie Blödsinn verzapft bekommen. Aber anscheinend stach die Münchner
> Niederlassung von denen in Punkto Qualität auch ziemlich hervor... Insofern
> verallgemeinere ich mal lieber nicht...
Ich selbst hatte bislang nichts mit Heidelberg zu tun, aber die Berichte
von Anwendern waren eher durchwachsen. Mag vielleicht daran liegen, dass
die Münchner Niederlassung für unseren Bereich zuständig ist ;-)
> > In unserem Fall entstehen >95 Prozent der Daten inhouse und sind deshalb
> > von Anfang an technisch in Ordnung.
>
> Aha. Und ihr übernehmt in all den Fällen auch niemals Fremddaten? Immer
> "from scratch"? Nie ein Bild im falschen Farbraum in ein selbst erstelltes
> EPS gebastelt? ,-)
Oh doch, auch sowas kam schon vor. Aber seit dem Composite-Workflow mit
ziemlich "umgänglichen" RIPs am Ende bügeln diese auch solche Fehler
weg. Bei der separierten Ausgabe war's schwieriger ...
> > Das dürfte auch erklären, warum wir bisher auf automatisierte
> > Kontrollwerkzeuge verzichten konnten, da wir die paar wenigen Anzeigen, die
> > von außen kommen, auch gut per Hand sichten können. In Deinem Fall sieht ds
> > natürlich anders aus.
>
> Ja, wobei ich "hausintern" für kein geeignetes Kriterium halte (vielleicht
> in Betrieben mit weniger als 5 Leuten noch?)
Schon vergessen, wir sind bloß vier ;-)
> [Polygonrahmen definieren Textfluß für Freisteller]
> Ich habe es bspw. *immer* wenn kein Pfadfreisteller nötig war (weil bspw.
> Personen einfach vor einen weissen Hintergrund gestellt werden mussten) so
> gehalten, daß ich den Freisteller "weich" erstellt habe (bisserl mit Pfad
> vorgezeichnet und dann ab in Maskierungsmodus und mit Pinsel und Radiergummi
> und Gaußschem Weichzeichner verkünstelt) und anschl. durch Umwandlung von
> Auswahl zu Pfad einen groben Pfadfreisteller mit mehreren Pixeln Abstand zur
> eigentlichen Freistellerkontur drumherumgelegt habe (damit die Grafiker in
> der Layoutphase zügig arbeiten können)
Klar, das machen wir auch ab und an so. Allerdings nur, wenn sicher ist,
dass der Kunde nicht auf einmal doch einen farbigen Hintergrund haben
will. Dann ist's nämlich Essig ...
[Rippen]
> > Ok, bei identischen RIPs sollte man dann wirklich davon ausgehen können,
> > dass es klappt ;-)
>
> Sie müssen nicht unbedingt identisch sein aber ähnliche Eigenschaften
> aufweisen. So kannst Du bspw. mit dem Interpreter eines Laserdruckers (der
> mit bspw. 600 dpi rippt) niemals Probleme simulieren, die durch "Flatness"
> Probleme erst später in der Kette passieren können.
Ack.
> Oder Positionierungsgeschichten, die sich bei 600 dpi nicht bemerkbar machen
> aber dann bei 2400 oder 2540 dpi.
Was meinst Du damit? Wenn man Farbflächen "nach Augenmaß"
aneinanderrückt und diese im Ausdruck optisch ok sind, aber beim
Belichten dann blitzen/überlappen?
> [Beschreibung, wie man aus einem A4-Katalog parallel auch eine partiell
> *andere* A5-Variante erstellen kann ohne zwei Korrektur-/Freigabezyklen]
>
> > Technisch sehr nett gelöst ;-)
>
> Ich glaube, Du hast eine relevante Information überlesen, nämlich, daß es
> nicht ein und derselbe Katalog war. Die farbige A4-Variante hatte andere
> Hintergrundabbildungen auf jeder Seite (leicht wolkige Abbildungen, die im
> s/w Offset nur nach mangelhaftem Druckergebnis ausgesehen hätten), hatte zum
> Teil andere Logoabbildungen (die feinere Variante, die in A5 durch
> einfacherer Grafiken ersetzt werden musste, weil die hellen Linien sonst
> zugesoffen wären) und noch ein paar Kleinigkeiten.
Sorry, das hatte ich nicht mitbekommen. Dann stimme ich Dir zu, das ist
sehr elegant und effektiv gelöst. Ich war von der simplen
Aufgabenstellung "Graustufen & Skalieren" ausgegangen, und dafür
erschien mir der Aufwand dann wiederum zu hoch.
> ... danach sank die Zeit für das Erstellen auf die für die Umwandlung
> einer Excel-Datei in eine tabseparierte Textdatei und das Aufrufen eines
> Skripts nötige, *wenn* keine Probleme auftraten, was natürlich nie vorkam
> ;-)
Wäre ja auch langweilig ;-)
> > Ich hätte es trotzdem anders gemacht: Quark-Dokument öffnen,
>
> Es wären 2.500 Dateien gewesen, die Du zweimal hättest anfassen müssen.
> Außerdem hättest Du bei der Summe an Eingriffen je Seite in jedem Fall zwei
> separate Korrekturläufe je Katalogvariante machen müssen (und es wären den
> Korrekturlesern mehr Fehler durchgerutscht, weil sie jede Seite zweimal
> hätten lesen müssen)
Schon klar, siehe oben.
> Ich halte Dir jetzt mal zugute, daß Du den wahren Aufwand nicht abschätzen
> konntest anhand meiner bisherigen vagen Beschreibung ;-)
Danke ;-)
> > Das hätte zwar vermutlich den Rechner länger in Beschlag genommen als
> > Deine Variante, allerdings wäre ich nach 30 Sekunden fertig gewesen ;-)
>
> Schon mal 2.500 leere Seiten aus Xpress am Stück zu drucken versucht? Wohl
> eher nein, oder? Denn selbst das geht nicht in 30 Sekunden (zumindest nicht
> am Mac mit den mir bekannten Rechnern). Abgesehen davon, daß bei mehr als
> 1000 Seiten am Stück die ulkigsten Dinge passieren (Absturz Xpress bis hin
> zu kompletten Lockups des Macs)
OK, ich war auch nicht von soooooo vielen Seiten ausgegangen. Außerdem
schrub ich, das ICH nach 30 Sekunden fertig wäre, und der Rechner da
sicherlich noch eine ganze Zeit zu rödeln hätte ;-)
> > Möglicher Nachteil (bei beiden Varianten): Keinen Einfluß auf Wiedergabe
> > der Graustufenbilder, da in beiden Fällen automatisch erstellt (Pitstop
> > Server vs. QXP).
>
> Die Umwandlung war durch Profil recht simpel möglich, da das alles
> technische Motive waren (da kann man die Farben prima verbiegen vorher,
> damit anschl. kontrastreiche s/w Abbildungen bekommt). Das wäre dann wieder
> die Colormanagement-Komponente des OPI-Servers gewesen :-)
ACK. Bis auf den Nachteil, den jeder der genannten Automatismen mit sich
bringt: Nämlich alle Bilder über einen Kamm zu scheren.
> > kann ich durch simples Benennen eines HELIOS-Ordners auch die gleichen
> > umfangreichen Parameter einstellen wie in einer PS-Aktion?
>
> Nein, wie denn auch? Die Parameter, die Du einem Ordner durch Benennung
> mitgeben kannst, sind sehr endlich (konkret abgesehen von Farbraum,
> Dateiformat und Auflösung sowieso keine).
>
> Was anderes ist, wenn Du mal die kleinen CLI-Tools 'layout', 'oiimginfo',
> 'psresolve' einsetzt. Man kann damit (und dem neuen scriptsrv im aktuellen
> ImageServer) recht mächtige Hotfolder einrichten, die anhand der Benennung
> des Ordners lernen, was sie zu tun haben, bspw. könnte ein Ordner
>
> 144_RGB_600_800_+.png
>
> in den Du ein CMYK und ein RGB-Profil reinwirfst dafür sorgen, daß alle
> hineingeschobenen Bilddateien auf 600x800 Pixel (bei Beibehaltung des aspect
> ratio und automatischer Skalierung auf den passenden x- oder y-Wert) als PNG
> (unter Berücksichtigung evtl. in den Bildern enthaltener Freisteller) mit
> 144 dpi abgespeichert werden.
Na, das ist doch schon mal was ;-)
> BTW: Mit einem der neuen HELIOS Updates von letzter Woche können jetzt mit
> dem 'layout' Tool auch Previews von Xpress-Dateien (und demnächst
> anscheinend auch InDesign) direkt auf dem Server extrahiert und umgebaut
> werden. Ich habe das bei einem Kunden jetzt bereits so laufen, daß von allen
> Xpress-Dokumenten, die sich ändern immer gleich die entsprechenden
> Vorschauen (bei Bedarf als Doppelseitenansicht zusammengebaut) als PDF in
> eine Datenbank geschoben werden. Es ist nur nötig, [Apfel][S] zu drücken,
> der Rest geschieht unauffällig im Hintergrund und für niemanden umgehbar
> (bzw. zu vergessen; das war das eigentliche Ziel der Aktion, unvermeidabre
> menschliche Nachlässigkeiten zu verunmöglichen)
Wenn das jetzt nicht nur mit der Vorschau, sondern auch mit den
eigentlichen Daten klappen würde, wäre das sehr interessant: Datei in
XPress abspeichern, und EPS mit korrekten Bildern und eingebundenen
Fonts wird automatisch erstellt. Aber dazu müsste HELIOS vermutlich
einen Großteil der QXP-Engine lizensieren ;-(
> >> [...]
> >> dieses Feature (die Grobdaten eben nicht auf Gedeih und Verderb mit den
> >> Feindaten zu koppeln) macht für mich eine der grössten Stärken des Servers
> >> aus! Ohne diese Funktionalität sind nahezu alle erweiterten Workflows, die
> >> wirklich von den OPI-Funktionalitäten Gebrauch machen (also alles, was über
> >> "schneller spoolen" hinausgeht!) weitestgehend nutzlos.
> >
> > Birgt das nicht irgendwo die Gefahr, dass Quark alle Bilder mit "OK"
> > bewertet, aber es dann bei der Ausgabe ein Desaster gibt, weil doch
> > einige HighRes-Daten fehlen?
>
> Nenne es nicht Desaster sondern angepeilter Einsatzzweck ;-)
>
> In dem länglichen Beispiel, daß ich letztens postete, benutzte ich genau
> das, um sicherzustellen, daß auch alle hausintern entstandenen Scans
> *definitiv* den Arbeitsplatz eines Retuscheurs gestreift haben.
So gesehen hast Du Recht, aber ich habe dann _direkt in QXP_ keine
Möglichkeit mehr, die Verfügbarkeit und den Status der Bilder zu
überprüfen.
> > Wenn ich OPI richtig verstanden habe, werden doch in QXP nur die .lay-Daten
> > platziert, ohne dass QXP überprüfen könnte, ob die Originale noch vorhanden
> > sind.
>
> Ja. Das ist mitunter einer der Grundgedanken hinter OPI. Du kannst die
> Grobdaten jemandem zum Layouten geben und diese enthalten nur eine Referenz
> auf die Feinbilder (nach bspw. absolutem Pfad, parallel File-ID und können
> bei Bedarf durch erweiterte Methoden wie bspw. der manuellen Zuordnung von
> Suchpfaden verfeinert werden). Layoutet werden kann also völlig unabhängig
> von der Verfügbarkeit der Feindaten.
Wobei diese Funktion in Quark per se vorhanden ist, da QXP für alle
importierten Bilder eine PICT-Preview anlegt. Es reicht also, wenn ich
zum Layouten nur die QXP-Datei weitergebe. In FreeHand geht das zum
Beispiel nicht. Allerdings ist "richtiges" OPI nicht nur auf die
Erstellung von Layout-Previews beschränkt ;-)
> > Das verstehe ich jetzt nich so ganz. Was haben klare Ordnerstrukturen
> > mit .lay-Waisen zu tun?
>
> Wie können denn verwaiste Grobbilder auf einem Server entstehen? Indem ich
> die Feinbilder irgendwohin auslagere (denn wenn ich sie nur verschiebe, dann
> können sie ja noch anhand der File-ID gefunden werden). Nur warum sollte
> mich dieser Vorgang überraschen? Entweder es ist Absicht, daß die Feindaten
> grad auf Tape-Library ausgelagert sind (und der Disponent in der
> Sachbearbeitung das Wiedereinlagern an den Ursprungsort jederzeit wieder
> triggern kann) oder die Feindaten stehen nicht im Zugriff, weil sie bspw.
> gerade vom Kunden als _veraltet_ definiert wurden und deshalb nicht mehr
> benutzt werden *dürfen*.
Das würde aber bedeuten, dass ich immer 2 Ordner im Auge behalten muss,
den eigentlichen Bilder- und den "Layouts"-Ordner. Und, um bei Deinem
Beispiel zu bleiben, was macht es für einen Sinn, ein Grobbild zu haben,
dass ich sowieso nicht mehr verwenden darf?
> > Ein Bild mit 72 dpi (immer bei 100% Skalierung, versteht sich) ist bei
> > einer hochauflösenden Druckausgabe immer irgendwie "defekt" ;-)
>
> Oder Stilmittel ;-)
Auch möglich, aber setzen wir mal voraus, dass es KEIN Stilmittel sein
soll ...
> Nee, im Ernst: Es hängt eben von der Skalierung in der Layoutanwendung ab,
> ob 72 dpi als gut oder böse zu bewerten sind. Nur kann ich das ja auch nur
> überprüfen, wenn ich einerseits Bildauflösung und andererseits Skalierung im
> Programm gleichzeitig betrachte und dabei die effektive Auflösung im
> fertigen Druckerzeugnis ermittele (was -- wenn man Photoshop benutzt --
> sowieso schwer fällt, da Photoshop manches mal nicht die Auflösung aus den
> eigentlich dafür vorgesehenen Metadatenfeldern in Bilddateien ausliest
> (bspw. die entsprechenden JPEG-Marker bei JFIF) sondern seine eigenen
> proprietären in den "Adobe Resource Blocks" benutzt und wenn diese fehlen
> einfach dreist behauptet, 72 dpi vor sich zu haben!)
>
> >>> Und erst wenn bei der Ausgabe der Job in der Fehlerqueue landet,
> >>
> >> Wieso sollte er da landen? Sicher nicht wegen 72 dpi, denn das prüfe ich
> >> nicht.
> >
> > Warum?
>
> Einerseits die Notwendigkeit, die effiziente Auflösung zu überprüfen (was
> ich automatisiert nur über Werkzeuge wie bspw. PitStop Server resultierend
> aus dem Druckjob an sich kann) und andererseits, weil es sich um ein
> Stilmittel handeln könnte.
Das Ganze hängt aber auch von der verwendeten Arbeitsweise ab. Bei uns
werden Bilddaten bereits im ersten Schritt _ohne Interpolation_ auf die
korrekte Auflösung gebracht. Wir platzieren dann die Bilder mit maximal
125% im Layout. Wenn mehr nötig ist, interpolieren wir in PS auf maximal
200% der Originalgröße. Dann ist Schluß ;-)
Interessant wäre die 72dpi-Prüfung in unserem Fall, falls mal ein Bild
versehentlich mit 72 dpi durchrutscht.
> >> Es kommt eben immer auf den Einsatzzweck des Bildes an. Wenn so ein Bild
> >> partout als Aufmacher mit 100% eingebaut werden soll, dann fällt das
> >> allerspätestens auf dem Proof auf, daß das nicht der Weisheit letzter
> >> Schluss ist.
> >
> > Aber eben erst auf dem Proof. IMHO ist das bereits zu spät, da dann ja
> > bereits unnötige Kosten entstanden sind. Auch wenn's _nur_ ein Proof
> > ist.
>
> Ja, aber da kommt es eben auf das an, was mit dem Kunden vereinbart ist und
> wie sehr er gewillt ist, selbst Verantwortung für seine angelieferten Daten
> zu übernehmen. Will er das nicht, dann werden die Serverqueues eben so
> verkettet, daß zuerst der PitStop Server Durchlauf erfolgt und nur nach
> erfolgreichem Aussortieren in den "OK" Ordner der zwischenzeitlich geparkte
> Druckjob weiter auf's Proof durchgereicht wird.
Bei uns werden Fremddaten zunächst immer "as is" verarbeitet. Wenn ein
Zulieferer also partout der Meinung ist, 72 dpi würden reichen ("...
weil das ja auf dem Tintenspritzer auch sauber rüberkommt." ;-), dann
darf er sich beim Aufschlagen der Zeitung und dem nachfolgenden
Telefonat mit mir gerne eines Besseren belehren lassen ;-)
Was aber nicht heißt, dass ich nicht schon vorher Alarm schlage, wenn
mir so etwas auffällt. Allerdings sehe ich nicht ein, bei umfangreichen
Anzeigen jedes einzelne Bild zu öffnen.
> BTW: Das A&O beim Aufspannen solcher Workflows ist übrigens die ausführliche
> Dokumentation des Ganzen. Sonst sind die Leute binnen kürzester Zeit reif
> für die Klapse :-)
Kann ich mir vorstellen ;-)
> >> Naja, der direkte PDF-Export hat es halt in sich (weil so nah dran am
> >> PDF-Standard, daß man merkt, daß es leider kein Ausgabegerät gibt, das da
> >> noch mithalten kann). Aber wenn man ein PS3-RIP unterm Tisch stehen hat
> >> (<hüstel>) dann ist das doch alles kein Problem, oder?
> >
> > Ist das wirklich so einfach? Wir haben insgesamt drei PS 3-RIPs (Viper,
> > Torrent und Epson Laserdrucker), aber keines davon kommt mit PDF-Dateien
> > ordentlich klar.
>
> Ein "PS 3 RIP" ist keine hinreichende Voraussetzung für direkte PDF-Ausgabe
> (es braucht bei original Adobe Interpretern mindestens 3011.106 und das
> Torrent sollte Scriptworks 5.3 oder höher beinhalten; bzgl. des Epson fehlt
> mir der Name des RIPs um sinnvollen Senf abgeben zu können). Schick mal das
> Folgende als PS-File auf die RIPs und guck nach:
>
> %!PS
> /Courier findfont 10 scalefont setfont
> 50 60 moveto
> version cvr 200.000 ge {
> (Interpreter: ) show product show
> 50 100 moveto
> (PS-Level: ) show languagelevel 1 string cvs show
> 50 80 moveto
> (Version: ) show version show
> }
> { (PS-Level: 1 Version: ) show version show
> } ifelse
> showpage
Das werde ich die Tage mal testen und Bericht erstatten ;-)
> > Erst ein Rückwandeln in PS mittels Acrobat funktioniert eigentlich immer
> > reibungslos.
>
> Yo. Und das ist aus mehreren Gründen oftmals nicht der falscheste Weg (bspw.
> Konflikte mit Schriftnamen zwischen Dokument und Interpreter-residetnen
> Schriften ausgeschlossen, sauberere Parametrisierung der InRIP Separation,
> etc. --> Crackerjack oder PDF Output Pro können übers Jahr gesehen diverse
> Quadratkilometer Film sparen)
Yepp.
Ciao
Achim
Thomas Kaiser
<news:1fpvglp.hxvg9f1qaef86N%use...@dtpd.com>:
> Ich selbst hatte bislang nichts mit Heidelberg zu tun, aber die Berichte
> von Anwendern waren eher durchwachsen. Mag vielleicht daran liegen, dass
> die Münchner Niederlassung für unseren Bereich zuständig ist ;-)
*g* Mir ist zwischenzeitlich übrigens schon wieder ein gravierender
Denkfehler meinerseits aufgefallen. Wir haben damals fast den ganzen
Gemüsegarten von Linotype/Heidelberg am Laufen gehabt (also SignaStation
noch unter NextStep später OpenStep, Server zum Glück schon Sun und nicht
mehr DG-UNIX <schüttel>, Delta-RIP unter NT 3.5 später 4.0, LinoColor auf
MacOS 8 und gegen Ende sogar NewColor unter Windows)
Dazu dann konsequent Hardware-Betatests (SignaSetter und zeitweise mal Topaz
III vor Ort) und dito mit Software (LinoColor, DeltaTec, später Prinergy).
Schließlich noch bedingt durch den Wahn, die Software bis zum Anschlag
ausreizen zu wollen, nahezu "unsupportbar" geworden :-))
Bzgl. der Delta-RIPs war es irgendwann tatsächlich so, daß Heidelberg keine
Verantwortung mehr übernehmen wollte (derweil hatte ich noch gar nicht
richtig losgelegt mit dem Optimieren -- NT auf geeigneter Hardware konnte
wirklich geil sein :-) und ankündigte, den Support komplett einzustellen.
Letzten Endes haben sie dann aber ein paar fitte Techniker geschickt, die
dann glubschäugig vor der "nicht mehr wartbaren Konfiguration" sassen und
sich an 80-100 MByte/sek Plattendurchsatz sattsahen (wohlgemerkt auf
identischer Hardware wie "normale" Delta-RIPs bloß halt mal mit korrekter
Partitionierung und StripeSets). Ein halbes Jahr später habe ich bei einem
anderen Techniker das Setup dann als sog. "Performance Konfiguration" in
seiner Mappe gefunden.
Will meinen: Bedingt durch das hohe Niveau beim Anwender (uns) und die
unbedingte Bereitschaft zu nerven, hatte ich regelmässig nur Kontakt mit
deren Spitzentechnikern und einem einzigen Verkäufer (der war übrigens der
Beste von allen -- selten wieder so einen angenehmen getroffen)
Also: Ich kann die auch nicht wirklich beurteilen, ziehe daher die Aussage
einfach wieder zurück ;-)
> [Rippen]
>> Oder Positionierungsgeschichten, die sich bei 600 dpi nicht bemerkbar machen
>> aber dann bei 2400 oder 2540 dpi.
>
> Was meinst Du damit?
Ich finde meine Mails nicht mehr. Grad ein paar Mailinglistenarchive lokal
durchkämmen lassen aber die Suchbegriffe passen nicht.
Es war auf alle Fälle was mit PS-Code aus Xpress heraus, der in Abhängigkeit
von der Zielgeräteauflösung mal passte und mal nicht.
> Wenn man Farbflächen "nach Augenmaß" aneinanderrückt und diese im Ausdruck
> optisch ok sind, aber beim Belichten dann blitzen/überlappen?
Das ist das Problem mit dem dollen Programm Xpress, das einfach zu blöde
ist, exakte Positionierungswerte in den PS-Code einzustreuen (siehe auch
Positinierung der Schneidzeichen, die auch im Zeitalter volldigitaler
Bogenmontage noch gerundet auf PostScript-Point positioniert werden.
Anscheinend getreu dem Motto, daß der Bogenmontierer normalerweise sowieso
zu betrunken ist, solche Feinheiten beim Montieren umzusetzen)
> [...] OK, ich war auch nicht von soooooo vielen Seiten ausgegangen.
So viele sind das gar nicht, wie ich vor kurzem bemerken musste, als ich für
ein anderes Projekt die Randbedingungen erfahren habe ;-))
> Außerdem schrub ich, das ICH nach 30 Sekunden fertig wäre, und der Rechner
> da sicherlich noch eine ganze Zeit zu rödeln hätte ;-)
Im Falle von Xpress würde ich auf "endlos" tippen. Aber wahrscheinlich
stelle ich mich immer zu blöde an. Jedenfalls fährt es mir Xpress
regelmässig jenseits tausend Seiten bei der Ausgabe gegen die Wand :-(
>> Die Umwandlung war durch Profil recht simpel möglich, da das alles
>> technische Motive waren (da kann man die Farben prima verbiegen vorher,
>> damit anschl. kontrastreiche s/w Abbildungen bekommt). Das wäre dann wieder
>> die Colormanagement-Komponente des OPI-Servers gewesen :-)
>
> ACK. Bis auf den Nachteil, den jeder der genannten Automatismen mit sich
> bringt: Nämlich alle Bilder über einen Kamm zu scheren.
Stimmt. Aber einerseits kann das funktionieren, wenn die Bilder alle gewisse
Kriterien aufweisen (Produktabbildungen, klar definierte CI-Farben, keine
"Fleischtöne" enthalten) und andererseits habe ich die für den
Freigabetyklus erstellten Korrekturseiten "natürlich" mit dem modifizierten
s/w Bildmaterial erstellt, damit der Kunde in der kritischen s/w Variante
ggf. auch die Bilder korrigieren lassen kann.
Ausgedruckt wurde übrigens auf zwei HPs (4050N und 6P), die beide komplett
vorgerasterte Seiten als PCL-Jobs bekommen haben (und deshalb problemlos in
Kopiergeschwindigkeit drucken konnten, wenn die RIPs -- alle PCs auf denen
GhostScript nebenher lief -- schnell genug waren). Selbstverständlich vorher
automatisch noch entsprechend die Gradation angepasst und frequenzmoduliert
aufgerastert, damit aus popeligen s/w Ausdrucken beinahe Qualitätsproofs
wurden :-)
[scriptsrv Aktion zum Erstellen von Previews für Xpress-Dateien]
> Wenn das jetzt nicht nur mit der Vorschau, sondern auch mit den
> eigentlichen Daten klappen würde, wäre das sehr interessant: Datei in
> XPress abspeichern, und EPS mit korrekten Bildern und eingebundenen
> Fonts wird automatisch erstellt.
Wenn irgendwo ein Mac mit allen Schriften im Zugriff rumsteht, dann kann man
sowas schon via Jobtickets triggern und bei Bedarf automatisiert EPS (oder
besser PDF) erzeugen.
> Aber dazu müsste HELIOS vermutlich einen Großteil der QXP-Engine lizensieren
Es gibt XTensions, die sich sehr tief in die Xpress-Struktur einklinken
(bspw. die DATAform Xtension). Aber man kann bspw. via AppleEvents Xpress
auch gefügig machen und direkt dazu bringen, daß es derlei Aktionen ausführt
(mit all den Risiken wie falschen Schriften, etc.)
BTW: Habe heute vernommen, daß Helios dem pdfinfo CLI-Tool nun ebenfalls ein
paar Prüfkriterien beibringt, die bisher noch den Einsatz von bspw. PitStop
Server nötig machten. Damit kann man den Preflight hinsichtlich Auflösung,
Feinbildfarbraum, etc. auch in PDFs direkt auf dem Server prüfen (und das
bspw. gleich transparent in den PDF-Erstellungsvorgang via Create-PDF
Druckerwarteschlange integrieren). Interessante Entwicklungen, die sich da
abzeichnen :-)
> ich habe dann _direkt in QXP_ keine Möglichkeit mehr, die Verfügbarkeit und
> den Status der Bilder zu überprüfen.
Jein. Entweder Du hilfst Dir per AppleScript oder benutzt spezialisierte
XTensions -- so das überhaupt nötig ist (und ich behaupte jetzt mal, daß es
das nicht ist, wenn man seine "Workflows" entsprechend plant)
>> [...] Layoutet werden kann also völlig unabhängig von der Verfügbarkeit
>> der Feindaten.
>
> Wobei diese Funktion in Quark per se vorhanden ist, da QXP für alle
> importierten Bilder eine PICT-Preview anlegt. Es reicht also, wenn ich
> zum Layouten nur die QXP-Datei weitergebe.
Das geht aber nicht in Situationen, in denen das Fototeam grad in Miama
knipst, die Freisteller-Leute in Asien hocken und die Agentur, die die
Katalogseite bauen soll, irgendwo hierzulande.
In solchen Fällen (wenn ein stark komprimiertes JPEG des Feinbilds nach
Asien geschoben wird zum Freistellen, das Feinbild Richtung Kunde unterwegs
ist, die Freistellpfade danach auf dem Server des Kunden "gemerged" werden,
und die Agentur sich per Web das Grobbild inkl. Freisteller zieht) dann gibt
es noch nirgends ein Feinbild, das irgendwer in Xpress hätte einbauen können
(Zeitverschiebung und sowas)
> In FreeHand geht das zum Beispiel nicht. Allerdings ist "richtiges" OPI
> nicht nur auf die Erstellung von Layout-Previews beschränkt ;-)
Yo. In letztgenanntem Beispiel bspw. erhält die Litho von der Agentur die
Xpress-Datei und zieht sich dank der in den Grobbildern enthaltenen
Referenzen die eigentlichen Feinbilder über ein Progrämmchen direkt übers
Web aus einer Bilddatenbank, um sie dann anschließend zu retuschieren.
>> Entweder es ist Absicht, daß die Feindaten grad auf Tape-Library
>> ausgelagert sind [...] oder die Feindaten stehen nicht im Zugriff, weil
>> sie bspw. gerade vom Kunden als _veraltet_ definiert wurden und deshalb
>> nicht mehr benutzt werden *dürfen*.
>
> Das würde aber bedeuten, dass ich immer 2 Ordner im Auge behalten muss,
> den eigentlichen Bilder- und den "Layouts"-Ordner.
Ich habe eigentlich bisher weder den einen noch den anderen im Auge
behalten. Man definiere den Workflow, sorge dafür, daß die beteiligten
Menschen *wirklich* verstehen, worum es geht, diskutiere das mit ihnen,
lasse sie alle bei vollem Bewußtsein bestätigen, daß ihnen auch nix
Besseres einfällt und... arbeite einfach. Geht herrlich simpel :-)
Fehlt das Grobbild, dann gibt es einen Grund, fehlt das Feinbild, dann
ebenso.
Man darf bloß niemals den Fehler machen, Menschen für Deppen zu verkaufen
und sie zu blossen Anhängseln der Maschine zu degradieren. Wenn man schon
auf hohem technischen Niveau produziert, dann muss trotzdem der Mensch im
Zentrum der Überlegungen stehen und dann klappt das Ganze auch...
> Und, um bei Deinem Beispiel zu bleiben, was macht es für einen Sinn,
> ein Grobbild zu haben, dass ich sowieso nicht mehr verwenden darf?
Hausintern den Vorteil der zeitlichen Entzerrung (Du erinnerst Dich: Setzer
kann anfangen, zu layouten lange bevor Feindaten auskorrigiert sind) und
global für so Sachen wie der Rechtsabteilung eines Konzerns via simplem
Webinterface (Bilddatenbank) die Möglichkeit zu geben, Bilder zu sperren,
deren Verwertungsrechte ungeklärt sind (mit denen aber vorher tatsächlich
schon aus zeitlichen Gründen gearbeitet wird).
> Bei uns werden Bilddaten bereits im ersten Schritt _ohne Interpolation_
> auf die korrekte Auflösung gebracht.
Das spare ich mir halt.
> Wir platzieren dann die Bilder mit maximal 125% im Layout. Wenn mehr nötig
> ist, interpolieren wir in PS auf maximal 200% der Originalgröße. Dann ist
> Schluß ;-)
Kennst Du die Lanczos Algorithmen zum Hochskalieren? IMO qualitativ deutlich
besser als die bikubische Variante...
> Interessant wäre die 72dpi-Prüfung in unserem Fall, falls mal ein Bild
> versehentlich mit 72 dpi durchrutscht.
Hehe, und genau das geht demnächst automatisch auf dem Server basierend auf
der effektiven Auflösung und nicht der Bildauflösung. Das macht das
Einbetten dieses Postflight-Checks deutlich simpler als bisher mit der
hakeligen Interaktion mit PitStop (Server)
> Bei uns werden Fremddaten zunächst immer "as is" verarbeitet. Wenn ein
> Zulieferer also partout der Meinung ist, 72 dpi würden reichen ("...
> weil das ja auf dem Tintenspritzer auch sauber rüberkommt." ;-), dann
> darf er sich beim Aufschlagen der Zeitung und dem nachfolgenden
> Telefonat mit mir gerne eines Besseren belehren lassen ;-)
Aber so in etwa beschrieb ich meinen Ansatz ja auch, in der Form, daß ich
dem Kunden zutraue (mit allen für ihn evtl. negativen Konsequenzen) zu
wissen, daß er 72 dpi Bilder mit maximal 25% Skalierung verwenden darf :-)
> Was aber nicht heißt, dass ich nicht schon vorher Alarm schlage, wenn
> mir so etwas auffällt. Allerdings sehe ich nicht ein, bei umfangreichen
> Anzeigen jedes einzelne Bild zu öffnen.
ACK -- da lobe ich mir einen Automatismus, der anschlagen kann, wenn der Job
über den Server huscht.
>> [...] Schick mal das Folgende als PS-File auf die RIPs und guck nach:
> [...]
> Das werde ich die Tage mal testen und Bericht erstatten ;-)
Ach, und definiere bei den RIPs vorher die Standardseitengrösse möglichst
gering, da in dem PS-Code jegliche Angaben zur "Page geometry" fehlen...
Wäre ja blöd, wenn für drei Zeilen Text ein Quadratmeter Film aus dem
Belichter fällt ;-)
Gruss,
Thomas
Achim Denzl
> Also: Ich kann die auch nicht wirklich beurteilen, ziehe daher die Aussage
> einfach wieder zurück ;-)
OK. Obwohl wir uns ja trotzdem ziemlich einig waren ;-)
> > [Rippen]
> >> Oder Positionierungsgeschichten, die sich bei 600 dpi nicht bemerkbar
> >> machen aber dann bei 2400 oder 2540 dpi.
> > Wenn man Farbflächen "nach Augenmaß" aneinanderrückt und diese im Ausdruck
> > optisch ok sind, aber beim Belichten dann blitzen/überlappen?
>
> Das ist das Problem mit dem dollen Programm Xpress, das einfach zu blöde
> ist, exakte Positionierungswerte in den PS-Code einzustreuen (siehe auch
> Positinierung der Schneidzeichen, die auch im Zeitalter volldigitaler
> Bogenmontage noch gerundet auf PostScript-Point positioniert werden.
> Anscheinend getreu dem Motto, daß der Bogenmontierer normalerweise sowieso
> zu betrunken ist, solche Feinheiten beim Montieren umzusetzen)
Mal abgesehen von QXP- und Montagefehlern (Hicks!) sind's aber oft auch
die Anwender, die Objekte nicht numerisch positionieren und oft gar
nicht wissen, welche (wirklich genialen) Rechenoperationen QXP in allen
(!) Eingabefelder beherrscht ;-)
> > [...] OK, ich war auch nicht von soooooo vielen Seiten ausgegangen.
>
> So viele sind das gar nicht, wie ich vor kurzem bemerken musste, als ich für
> ein anderes Projekt die Randbedingungen erfahren habe ;-))
>
> > Außerdem schrub ich, das ICH nach 30 Sekunden fertig wäre, und der Rechner
> > da sicherlich noch eine ganze Zeit zu rödeln hätte ;-)
>
> Im Falle von Xpress würde ich auf "endlos" tippen. Aber wahrscheinlich
> stelle ich mich immer zu blöde an. Jedenfalls fährt es mir Xpress
> regelmässig jenseits tausend Seiten bei der Ausgabe gegen die Wand :-(
Man definiere in QXP ein "Buch", das aus lauter kleinen, handlichen
Kapiteln besteht. Das klappt im Regelfall deutlich besser als ein
einzelnes Monsterdokument. Wobei ich das mit >1000 Seiten auch noch
nicht probiert habe ...
[...]
> Ausgedruckt wurde übrigens auf zwei HPs (4050N und 6P), die beide komplett
> vorgerasterte Seiten als PCL-Jobs bekommen haben (und deshalb problemlos in
> Kopiergeschwindigkeit drucken konnten, wenn die RIPs -- alle PCs auf denen
> GhostScript nebenher lief -- schnell genug waren). Selbstverständlich vorher
> automatisch noch entsprechend die Gradation angepasst und frequenzmoduliert
> aufgerastert, damit aus popeligen s/w Ausdrucken beinahe Qualitätsproofs
> wurden :-)
Apropos HP-Drucker: Möglicherweise steht demnächst die Anschaffung eines
DesignJet 500PS an. Hast Du (gute/schlechte) Erfahrung mit HP-LFPs? Ich
grüble gerade noch über die Anbindung nach: USB scheidet aufgrund von
Geschwindigkeit und WinNT als RIP aus, parallel würde ich momentan
bevorzugen, alternativ noch 100BaseTX, was ich aber bei der relativ
langsamen Druckausgabe eher für überflüssig halte ...
> [scriptsrv Aktion zum Erstellen von Previews für Xpress-Dateien]
> > Wenn das jetzt nicht nur mit der Vorschau, sondern auch mit den
> > eigentlichen Daten klappen würde, wäre das sehr interessant: Datei in
> > XPress abspeichern, und EPS mit korrekten Bildern und eingebundenen
> > Fonts wird automatisch erstellt.
>
> Wenn irgendwo ein Mac mit allen Schriften im Zugriff rumsteht, dann kann man
> sowas schon via Jobtickets triggern und bei Bedarf automatisiert EPS (oder
> besser PDF) erzeugen.
Gut, aber das geht mit Distiller-Hotfoldern oder FontIncluder-Server
auch, allerdings wieder mit dem Problem, dass die Datei zunächst
händisch aus QXP exportiert werden muss. Interessant wäre ein Tool, das
QXP-Daten direkt auf dem Server verarbeiten kann.
> > Aber dazu müsste HELIOS vermutlich einen Großteil der QXP-Engine lizensieren
>
> Es gibt XTensions, die sich sehr tief in die Xpress-Struktur einklinken
> (bspw. die DATAform Xtension). Aber man kann bspw. via AppleEvents Xpress
> auch gefügig machen und direkt dazu bringen, daß es derlei Aktionen ausführt
> (mit all den Risiken wie falschen Schriften, etc.)
Schon klar, aber das setzt voraus, dass das ganze auf einem Arbeitsplatz
stattfindet oder man sich traut, QXP auch auf dem Server laufen zu
lassen, was zumindest bei manchen Plattformen (Linux?) schwierig sein
dürfte. Außerdem kommen auf meine Server _niemals_ Anwendungsprogramme,
Basta! ;-)
> BTW: Habe heute vernommen, daß Helios dem pdfinfo CLI-Tool nun ebenfalls ein
> paar Prüfkriterien beibringt, die bisher noch den Einsatz von bspw. PitStop
> Server nötig machten. Damit kann man den Preflight hinsichtlich Auflösung,
> Feinbildfarbraum, etc. auch in PDFs direkt auf dem Server prüfen (und das
> bspw. gleich transparent in den PDF-Erstellungsvorgang via Create-PDF
> Druckerwarteschlange integrieren). Interessante Entwicklungen, die sich da
> abzeichnen :-)
Die haben bestimmt mit Spannung unsere Postings verfolgt ;-)
> >> [...] Layoutet werden kann also völlig unabhängig von der Verfügbarkeit
> >> der Feindaten.
> >
> > Wobei diese Funktion in Quark per se vorhanden ist, da QXP für alle
> > importierten Bilder eine PICT-Preview anlegt. Es reicht also, wenn ich
> > zum Layouten nur die QXP-Datei weitergebe.
>
> Das geht aber nicht in Situationen, in denen das Fototeam grad in Miama
> knipst, die Freisteller-Leute in Asien hocken und die Agentur, die die
> Katalogseite bauen soll, irgendwo hierzulande.
Mit genug Phantasie findet man immer ein Szenario, wo die eine oder
andere Methode nicht funktioniert ;-)
>
> In solchen Fällen (wenn ein stark komprimiertes JPEG des Feinbilds nach
> Asien geschoben wird zum Freistellen, das Feinbild Richtung Kunde unterwegs
> ist, die Freistellpfade danach auf dem Server des Kunden "gemerged" werden,
> und die Agentur sich per Web das Grobbild inkl. Freisteller zieht) dann gibt
> es noch nirgends ein Feinbild, das irgendwer in Xpress hätte einbauen können
> (Zeitverschiebung und sowas)
Sind Freisteller in Asien billiger? *g*
> > Und, um bei Deinem Beispiel zu bleiben, was macht es für einen Sinn,
> > ein Grobbild zu haben, dass ich sowieso nicht mehr verwenden darf?
>
> Hausintern den Vorteil der zeitlichen Entzerrung (Du erinnerst Dich: Setzer
> kann anfangen, zu layouten lange bevor Feindaten auskorrigiert sind) und
> global für so Sachen wie der Rechtsabteilung eines Konzerns via simplem
> Webinterface (Bilddatenbank) die Möglichkeit zu geben, Bilder zu sperren,
> deren Verwertungsrechte ungeklärt sind (mit denen aber vorher tatsächlich
> schon aus zeitlichen Gründen gearbeitet wird).
Dann muss ich ja ernsthaft darüber nachdenken, unsere Firma um eine
sechs- bis achtköpfige Rechtsabteilung zu erweitern ;-)
> > Bei uns werden Bilddaten bereits im ersten Schritt _ohne Interpolation_
> > auf die korrekte Auflösung gebracht.
>
> Das spare ich mir halt.
Aber irgendwann kommst Du trotzdem nicht umhin, die Bildauflösung zu
korrigieren ...
> > Wir platzieren dann die Bilder mit maximal 125% im Layout. Wenn mehr nötig
> > ist, interpolieren wir in PS auf maximal 200% der Originalgröße. Dann ist
> > Schluß ;-)
>
> Kennst Du die Lanczos Algorithmen zum Hochskalieren? IMO qualitativ deutlich
> besser als die bikubische Variante...
Nö, kenn ich nicht. Gibt's das als Photoshop-PlugIn?
> > Interessant wäre die 72dpi-Prüfung in unserem Fall, falls mal ein Bild
> > versehentlich mit 72 dpi durchrutscht.
>
> Hehe, und genau das geht demnächst automatisch auf dem Server basierend auf
> der effektiven Auflösung und nicht der Bildauflösung. Das macht das
> Einbetten dieses Postflight-Checks deutlich simpler als bisher mit der
> hakeligen Interaktion mit PitStop (Server)
Na also! Vielleicht sollten wir denen eine Rechnung schicken, wegen
Ideenklau oder so ;-)
> >> [...] Schick mal das Folgende als PS-File auf die RIPs und guck nach:
> > [...]
> > Das werde ich die Tage mal testen und Bericht erstatten ;-)
>
> Ach, und definiere bei den RIPs vorher die Standardseitengrösse möglichst
> gering, da in dem PS-Code jegliche Angaben zur "Page geometry" fehlen...
> Wäre ja blöd, wenn für drei Zeilen Text ein Quadratmeter Film aus dem
> Belichter fällt ;-)
Ich war - zugegeben - heute schon etwas überrascht, als auf einmal der
Film unter der Tür zum Belichterraum durchgekrochen kam ;-)
Nö, im Ernst, hat schon gepasst. Wenn ich heute mehr Zeit gehabt hätte,
hätte ich es bei der Ausgabe ins Logfile bewenden lassen anstatt
"richtigen" Output zu erzeugen ...
So, aber nun zu den Daten:
AGFA RIP 3010.105
Torrent 3010.0
EPSON EPL-N 2700 3010.103
Thomas Kaiser
<news:1fpz8bz.76zpnp1imuguaN%use...@dtpd.com>:
> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Jedenfalls fährt es mir Xpress regelmässig jenseits tausend Seiten bei
>> der Ausgabe gegen die Wand :-(
>
> Man definiere in QXP ein "Buch", das aus lauter kleinen, handlichen
> Kapiteln besteht. Das klappt im Regelfall deutlich besser als ein
> einzelnes Monsterdokument.
Hmm... ich mache in Xpress eigentlich so gut wie nie Satz (das machen die
Setzer -- die sind besser und billiger ;-) sondern meistens so Aktionen wie
in Text, der in "Xpress-Marken" formatiert ist, in Layouts einfließen
lassen. Das geht meistens zigfach schneller als direkt per AppleEvents in
Xpress Layouts bauen zu wollen. Und bei dem Kram für den ich das mache
(bspw. für Kataloge Barcodelisten erstellen --> je Katalogseite 1-3
Barcodeseiten) summiert sich das schnell zu erklecklichen Seitenzahlen.
> Wobei ich das mit >1000 Seiten auch noch nicht probiert habe ...
Ich schon... und ich habe eben irgendwann Routinen gebaut, die immer nur ein
paar hundert Seiten am Stück drucken...
>>> Datei in XPress abspeichern, und EPS mit korrekten Bildern und eingebundenen
>>> Fonts wird automatisch erstellt.
>>>
>> Wenn irgendwo ein Mac mit allen Schriften im Zugriff rumsteht, dann kann man
>> sowas schon via Jobtickets triggern und bei Bedarf automatisiert EPS (oder
>> besser PDF) erzeugen.
>
> Gut, aber das geht mit Distiller-Hotfoldern oder FontIncluder-Server auch,
Das wäre auch bei meiner Variante notwendige Voraussetzung gewesen...
> allerdings wieder mit dem Problem, dass die Datei zunächst händisch aus QXP
> exportiert werden muss.
Und eben das ist ein Anachronismus.
> Interessant wäre ein Tool, das QXP-Daten direkt auf dem Server verarbeiten
> kann.
Wenn das ein Mac ist, auf dem Xpress läuft, dann ist das halt per Definition
ein Automatisationsserver. Sowas ist durchaus öfter im Einsatz. Man nehme
noch FlightCheck dazu für die paar Spezialfälle bei denen Xpress beim Öffnen
auf die Nase fallen könnte und ansonsten kann man prima anhand von
Jobprofilen automatisiert Dateien annehmen, prüfen und ausgeben. Sowohl in
grossen Lösungen (siehe exemplarisch <http://www.rotheneder.com/hermes/>,
eine sehr aufgebohrte MarkzScout Anwendung) als auch selbstgeschnitzt bspw.
per AppleScript, wenn man eh weiß, was man will...
> aber das setzt voraus, dass das ganze auf einem Arbeitsplatz stattfindet
Genau, auf einem automatisierten Arbeitsplatz
> oder man sich traut, QXP auch auf dem Server laufen zu lassen, was zumindest
> bei manchen Plattformen (Linux?) schwierig sein dürfte.
Wenn es unter Linux in einer Windows-Sandbox läuft, dann ist ja nicht allzu
viel dagegen einzuwenden (außer der Sinnlosigkeit des Ganzen)
> Außerdem kommen auf meine Server _niemals_ Anwendungsprogramme, Basta! ;-)
Du legst den Begriff "Server" ein wenig engstirnig aus, scheint mir ;-)
>>> Wobei diese Funktion in Quark per se vorhanden ist, da QXP für alle
>>> importierten Bilder eine PICT-Preview anlegt. Es reicht also, wenn ich
>>> zum Layouten nur die QXP-Datei weitergebe.
>>
>> Das geht aber nicht in Situationen, in denen das Fototeam grad in Miama
>> knipst, die Freisteller-Leute in Asien hocken und die Agentur, die die
>> Katalogseite bauen soll, irgendwo hierzulande.
>
> Mit genug Phantasie findet man immer ein Szenario, wo die eine oder
> andere Methode nicht funktioniert ;-)
Du wirst lachen -- aber so viel Phantasie brauchte ich da gar nicht. Genau
das ist momentan ein weiterer Puzzlestein in einem grossen "Workflow"-
Projekt. Es ist schon sehr anspruchsvoll, serverbasiertes Arbeiten einführen
zu wollen, wenn die Leute teilweise auf der anderen Seite der Erdkugel
sitzen und pro Tag mehrere hunderte MByte Bilddaten produzieren (die man zum
Glück komprimieren kann und bei Einführung der von mir beschriebenen
Methoden auch nicht unbedingt online übertragen muss, sondern das auch per
Luftpost günstig erledigen kann ohne Zeitverluste in Kauf nehmen zu müssen)
>> In solchen Fällen (wenn ein stark komprimiertes JPEG des Feinbilds nach
>> Asien geschoben wird zum Freistellen, das Feinbild Richtung Kunde unterwegs
>> ist, die Freistellpfade danach auf dem Server des Kunden "gemerged" werden,
>> und die Agentur sich per Web das Grobbild inkl. Freisteller zieht) dann gibt
>> es noch nirgends ein Feinbild, das irgendwer in Xpress hätte einbauen können
>> (Zeitverschiebung und sowas)
>
> Sind Freisteller in Asien billiger? *g*
Als hier? Ja. Aber ich sage jetzt mal lieber nicht, um wieviel...
>>> Bei uns werden Bilddaten bereits im ersten Schritt _ohne Interpolation_
>>> auf die korrekte Auflösung gebracht.
>>
>> Das spare ich mir halt.
>
> Aber irgendwann kommst Du trotzdem nicht umhin, die Bildauflösung zu
> korrigieren ...
Warum denn? Die "Auflösung", die als Teil der klassischen Metadaten einem
Bild mitgegeben wird, ist doch alles andere als aussagekräftig, da die
effektive Auflösung, um die es für eine qualitative Beurteilung geht, durch
den Skalierungsfaktor im Layoutprogramm, definiert wird. Es zählt also nur
das, was nach Verrechnung der Bildauflösung mit der Skalierung letzten Endes
an echter Auflösung herauskommt. Und das weiß ich im ersten Schritt nicht
ohne mir das Layoutdokument angeschaut zu haben.
>>> Wir platzieren dann die Bilder mit maximal 125% im Layout. Wenn mehr nötig
>>> ist, interpolieren wir in PS auf maximal 200% der Originalgröße. Dann ist
>>> Schluß ;-)
>>
>> Kennst Du die Lanczos Algorithmen zum Hochskalieren? IMO qualitativ deutlich
>> besser als die bikubische Variante...
>
> Nö, kenn ich nicht. Gibt's das als Photoshop-PlugIn?
Keine Ahnung (google? ;-)
Ich benutzte es früher mit ImageAlchemy, später mit ImageMagick. Ich glaube
auch, daß das der default in LinoColor war, das ich früher für das
Hochinterpolieren eingesetzt habe, wenn ich nur einen Mac zur Verfügung
hatte.
>>> Interessant wäre die 72dpi-Prüfung in unserem Fall, falls mal ein Bild
>>> versehentlich mit 72 dpi durchrutscht.
>>
>> Hehe, und genau das geht demnächst automatisch auf dem Server basierend auf
>> der effektiven Auflösung und nicht der Bildauflösung. Das macht das
>> Einbetten dieses Postflight-Checks deutlich simpler als bisher mit der
>> hakeligen Interaktion mit PitStop (Server)
>
> Na also! Vielleicht sollten wir denen eine Rechnung schicken, wegen
> Ideenklau oder so ;-)
Naja, deren Ideen wurden schon deutlich vor unserer kleinen Diskussion
ausgebrütet. Mir ist übrigens eben gekommen, daß man den ganzen Check von
Xpress-Dateien auch schon ohne ein erzeugtes PDF direkt beim Speichern der
Quark-Dateien auf dem Server machen kann mit automatischer Benachrichtigung
der Operators, wenn die *effektive* *Feinbild*auflösung gewisse Grenzwerte
über- oder unterschreitet. Das dazu nötige Update hat Helios vor zwei Wochen
rausgebracht (XPPV-Xtension)
> So, aber nun zu den Daten:
> AGFA RIP 3010.105
> Torrent 3010.0
> EPSON EPL-N 2700 3010.103
Das AGFA und das Epson RIP (letzteres anscheinend auch ein original Adobe
Interpreter) sind nicht auf dem für direkte PDF-Verarbeitung nötigen Stand.
Das Torrent muß wie gesagt von der Scriptworks-Version her 5.3 oder höher
sein.
Gruss,
Thomas
Thomas Kaiser
<news:1fpz8bz.76zpnp1imuguaN%use...@dtpd.com>:
> Apropos HP-Drucker: Möglicherweise steht demnächst die Anschaffung eines
> DesignJet 500PS an. Hast Du (gute/schlechte) Erfahrung mit HP-LFPs?
Leider aktuell mit den grossen Farbdruckern nahezu gar keine. In der
Vergangenheit hatte ich nur HPs im Zugriff und einmal einen Epson 9000. Mich
hat der Drucker an sich aber immer recht wenig interessiert (Farbe auf
Papier -- who cares? ;-) sondern eher die RIP-Lösung und deren Fähigkeiten.
Naja gut, die Ausgabegschwindigkeit war natürlich wichtig, ein hinreichend
grosser abzubildender Farbraum und ein sauberes Medienhandling, damit die
Kisten nächtelang durchdrucken konnten ohne in der Früh 50% Makulatur durch
Spontanfalzung erzeugt zu haben ;-)
> Ich grüble gerade noch über die Anbindung nach: USB scheidet aufgrund von
> Geschwindigkeit
Wieso steht USB gegen die Geschwindigkeit? Angenommen die Bruttodatenrate
von 12 MBit/sek resultiert in ca. 4 MBit/sek effektiver Datenrate, dann sind
das immer noch 500 KByte/sek an Daten. Zwischen RIP und Drucker werden ja
nur noch Pixelinformationen übertragen, im Falle von PCL seit bald
Jahrzehnten auch in effizient komprimierter Form (RLE-, LZW- oder "Delta
Row"-Kompression möglich in Abhängigkeit vom Alter des Druckers)
Gehen wir von einem Kompressionsverhältnis von 1:3 aus, so bedeuten 10 Min.
Druckzeit für einen "grossen Lappen", daß das Spoolfile 900 MByte gross ist,
wenn USB tatsächlich der Flaschenhals sein sollte.
Eine Fläche von 1 Quadratmeter bei 360 dpi hat aber je Grundfarbe ca.
200.000.000 Pixel (eigentlich mit 1 Bit Tiefe, da die Druckköpfe aber
versetzt mehrfach die selben Ausgabepixel lasierend bedrucken gehen wir mal
von 4 Bit Tiefe aus), was dann zu ca. 100 MByte je Grundfarbe führt, die
sich bei 6 Farben zu satten 600 MByte zusammensummieren.
Hmm... wie lange braucht denn ein aktueller HP für 1x1 Meter?
> und WinNT als RIP aus,
Was spricht gegen NT? Die meisten PC-Kisten, die ich als Arbeitstiere in
unserem Gewerbe so kenne, laufen fast ausschließlich unter NT4/SP6
unauffällig und zufrieden stellend vor sich hin... und das wird wohl auch
noch die nächsten Jahre so bleiben, jetzt wo es zum Glück auch keine Updates
mehr gibt, die einem wahnsinnige Servicetechniker ungefragt einspielen :-)
> parallel würde ich momentan bevorzugen,
Und das ist schneller als USB Full-Speed?
> alternativ noch 100BaseTX, was ich aber bei der relativ langsamen Druckausgabe
> eher für überflüssig halte ...
Also ich kann mich noch an einen HP 1050 erinnern, vor dem ich fast heulend
stand und zusehen durfte, wie der rasend schnell 70x100 Formproofs gedruckt
hat. Ich hatte das Ausgabetempo eines 750C noch zu gut in Erinnerung mit dem
ich kurz vorher die Freigabebögen für einige fette Verlagsvorschauen
realiseren musste. Und da lagen Welten dazwischen. Wird wohl heutzutage eher
noch flotter sein?
Ich würde angesichts des Preises (damals immer so ca. 300 EUR Aufpreis für
die LAN-fähigen Printserver) zur LAN-Variante neigen, da man dann einfach
ein Eckchen flexibler ist. Und sei es nur, um mehr als ein RIP die Kiste
bedienen zu lassen. Du musst ja auch bedenken, daß selbst ein GhostScript
unter MacOS X völlig ausreicht, wenn man die ICC-Profilierung der Ausgabe
über einen Publishing-Server (oder bspw. auch direkt per ColorSync) angeht.
Es braucht ja nicht für alle Zwecke PosterShop, BestColor, GMG, GCS oder wie
sie alle heissen...
Gruss,
Thomas
Achim Denzl
> Hmm... ich mache in Xpress eigentlich so gut wie nie Satz (das machen die
> Setzer -- die sind besser und billiger ;-) sondern meistens so Aktionen wie
> in Text, der in "Xpress-Marken" formatiert ist, in Layouts einfließen
> lassen. Das geht meistens zigfach schneller als direkt per AppleEvents in
> Xpress Layouts bauen zu wollen. Und bei dem Kram für den ich das mache
> (bspw. für Kataloge Barcodelisten erstellen --> je Katalogseite 1-3
> Barcodeseiten) summiert sich das schnell zu erklecklichen Seitenzahlen.
<Schwärm>
Yep, XPress-Marken sind wohl eines der stärksten Features von XPress
(Gibt's sowas eigentlich auch in InDesign?). Für eine unserer
Publikationen erstellen wir regelmäßig einen Kalenderteil, der unter DOS
(!) erfasst wird. Ich habe ein RB-Programm gebastelt, das den Output des
DOS-Programm in XPress-Tags konvertiert, und mit wenigen Mausklicks ist
das ganze Teil fertig. Früher eine Arbeit von etlichen Stunden, heute
weniger als 5 Minuten.
</>
> > Wobei ich das mit >1000 Seiten auch noch nicht probiert habe ...
>
> Ich schon... und ich habe eben irgendwann Routinen gebaut, die immer nur ein
> paar hundert Seiten am Stück drucken...
Spezielle Routinen? Das kann ich doch auch Drucken-Dialog vorgeben,
1-100, 101-200 etc. ...
> > Interessant wäre ein Tool, das QXP-Daten direkt auf dem Server verarbeiten
> > kann.
>
> Wenn das ein Mac ist, auf dem Xpress läuft, dann ist das halt per Definition
> ein Automatisationsserver. Sowas ist durchaus öfter im Einsatz. Man nehme
> noch FlightCheck dazu für die paar Spezialfälle bei denen Xpress beim Öffnen
> auf die Nase fallen könnte und ansonsten kann man prima anhand von
> Jobprofilen automatisiert Dateien annehmen, prüfen und ausgeben. Sowohl in
> grossen Lösungen (siehe exemplarisch <http://www.rotheneder.com/hermes/>,
> eine sehr aufgebohrte MarkzScout Anwendung) als auch selbstgeschnitzt bspw.
> per AppleScript, wenn man eh weiß, was man will...
Von dem Hermes-System hab' ich schon was gehört. War wohl in PP ...
> > oder man sich traut, QXP auch auf dem Server laufen zu lassen, was zumindest
> > bei manchen Plattformen (Linux?) schwierig sein dürfte.
>
> Wenn es unter Linux in einer Windows-Sandbox läuft, dann ist ja nicht allzu
> viel dagegen einzuwenden (außer der Sinnlosigkeit des Ganzen)
>
> > Außerdem kommen auf meine Server _niemals_ Anwendungsprogramme, Basta! ;-)
>
> Du legst den Begriff "Server" ein wenig engstirnig aus, scheint mir ;-)
'tschuldigung. Ich dachte da explizit an File- und Printserver, speziell
an unseren ASIP-Server, auf dem außer Retrospect und der USV-Software
nichts darauf läuft. Was sich dann eben durch monate- bis jahrelange
Uptimes (sofern man nicht aus Wartungsgründen mal neustarten muss)
auszahlt.
Wir haben den ganzen anderen Kram (Cumulus, DNS, Leonardo sowie einige
Eigenentwicklungen) auf einem zweiten Server laufen sowie noch einen
dritten für Distiller und nochmals Leonardo.
Das hat für mich IMHO den Vorteil, dass unsere Daten auf dem ASIP in
einer möglichst unbeeinträchtigten Umgebung untergebracht sind. Und wenn
einer der anderen Server mal crashen sollte: Was soll's ...
> > Mit genug Phantasie findet man immer ein Szenario, wo die eine oder
> > andere Methode nicht funktioniert ;-)
>
> Du wirst lachen -- aber so viel Phantasie brauchte ich da gar nicht. Genau
> das ist momentan ein weiterer Puzzlestein in einem grossen "Workflow"-
> Projekt. Es ist schon sehr anspruchsvoll, serverbasiertes Arbeiten einführen
> zu wollen, wenn die Leute teilweise auf der anderen Seite der Erdkugel
> sitzen und pro Tag mehrere hunderte MByte Bilddaten produzieren (die man zum
> Glück komprimieren kann und bei Einführung der von mir beschriebenen
> Methoden auch nicht unbedingt online übertragen muss, sondern das auch per
> Luftpost günstig erledigen kann ohne Zeitverluste in Kauf nehmen zu müssen)
Das ist doch gerade das Schöne an unserem* Job, wenn man komplexe
Automatismen austüftelt und man dann (hoffentlich) sieht, wie brav ein
Zahnrädchen in das andere greift ;-)
[* ich hoffe, Du bist nicht beleidigt, wenn ich uns beide da mal in
einen Topf werfe ;-) ]
> > Aber irgendwann kommst Du trotzdem nicht umhin, die Bildauflösung zu
> > korrigieren ...
>
> Warum denn? Die "Auflösung", die als Teil der klassischen Metadaten einem
> Bild mitgegeben wird, ist doch alles andere als aussagekräftig, da die
> effektive Auflösung, um die es für eine qualitative Beurteilung geht, durch
> den Skalierungsfaktor im Layoutprogramm, definiert wird. Es zählt also nur
> das, was nach Verrechnung der Bildauflösung mit der Skalierung letzten Endes
> an echter Auflösung herauskommt. Und das weiß ich im ersten Schritt nicht
> ohne mir das Layoutdokument angeschaut zu haben.
Genau das ist das Problem, Du hast eine Gleichung mit zwei unbekannten:
Bildauflösung und Skalierung. Ich löse das eben so, dass ich eine davon
(nämlich die Bildauflösung) von vorne herein auf einen festen Wert
setze. Dann ist nämlich nur noch die Skalierng im Layout-Programm
maßgebend und evetuelle "Ausreißer" sind sofort sichtbar.
> > So, aber nun zu den Daten:
> > AGFA RIP 3010.105
> > Torrent 3010.0
> > EPSON EPL-N 2700 3010.103
>
> Das AGFA und das Epson RIP (letzteres anscheinend auch ein original Adobe
> Interpreter) sind nicht auf dem für direkte PDF-Verarbeitung nötigen Stand.
> Das Torrent muß wie gesagt von der Scriptworks-Version her 5.3 oder höher
> sein.
Gut, bei AGFA könnte man mal nachfragen wegen einem Update. Allerdings
wird das horrende Summen kosten, fürchte ich. Beim Epson geht vermutlich
nicht viel (eingebautes Hardware-RIP), und bei Torrent ist es
Scriptworks 5.1Rev2.
Leider ist die Seite von highwater.co.uk (das ist doch der Hersteller
von Torrent?) nicht sonderlich aussagekräftig. Hast du Erfahrungen mit
Scriptworks-Updates, insbesondere Preise?
Jochen Kremer
> Achim Denzl schrieb am 06.02.2003 21:14 Uhr in
> <news:1fpz8bz.76zpnp1imuguaN%use...@dtpd.com>:
>
>>und WinNT als RIP aus,
>
> Was spricht gegen NT? Die meisten PC-Kisten, die ich als Arbeitstiere in
> unserem Gewerbe so kenne, laufen fast ausschließlich unter NT4/SP6
> unauffällig und zufrieden stellend vor sich hin... und das wird wohl auch
> noch die nächsten Jahre so bleiben, jetzt wo es zum Glück auch keine Updates
> mehr gibt, die einem wahnsinnige Servicetechniker ungefragt einspielen :-)
Wenn ich jetzt mal ausschließe, daß ich in der näheren Vergangenheit
gaaanz Wesentliches verpaßt hab', dürfte die Kombination von NT und USB
zum Scheitern verurteilt sein. NT 'kennt' kein USB.
Schöne Grüße
Jochen
Achim Denzl
> > Apropos HP-Drucker: Möglicherweise steht demnächst die Anschaffung eines
> > DesignJet 500PS an. Hast Du (gute/schlechte) Erfahrung mit HP-LFPs?
>
> Leider aktuell mit den grossen Farbdruckern nahezu gar keine. In der
> Vergangenheit hatte ich nur HPs im Zugriff und einmal einen Epson 9000. Mich
> hat der Drucker an sich aber immer recht wenig interessiert (Farbe auf
> Papier -- who cares? ;-) sondern eher die RIP-Lösung und deren Fähigkeiten.
In Falle des HP DJ 500PS wäre ein HP-eigenes Software-RIP für Mac und PC
dabei; das sollte es für den Anfang eigentlich tun, zumal in nächster
Zeit damit sowieso nur Großfotos gedruckt werden und deshalb auch der
Weg über TIFFs und den "normalen" Windows-Treiber ohne RIP möglich wäre.
> Naja gut, die Ausgabegschwindigkeit war natürlich wichtig, ein hinreichend
> grosser abzubildender Farbraum und ein sauberes Medienhandling, damit die
> Kisten nächtelang durchdrucken konnten ohne in der Früh 50% Makulatur durch
> Spontanfalzung erzeugt zu haben ;-)
Das Teil ist angeblich speziell für den unbeaufsichtigten Druck
konzipiert, die Druckgeschwindigkeit mit 2,2 m2/h bei höchster Qualität
eher niedrig.
> > Ich grüble gerade noch über die Anbindung nach: USB scheidet aufgrund von
> > Geschwindigkeit
>
> Wieso steht USB gegen die Geschwindigkeit? Angenommen die Bruttodatenrate
> von 12 MBit/sek resultiert in ca. 4 MBit/sek effektiver Datenrate, dann sind
> das immer noch 500 KByte/sek an Daten. Zwischen RIP und Drucker werden ja
> nur noch Pixelinformationen übertragen, im Falle von PCL seit bald
> Jahrzehnten auch in effizient komprimierter Form (RLE-, LZW- oder "Delta
> Row"-Kompression möglich in Abhängigkeit vom Alter des Druckers)
>
> Gehen wir von einem Kompressionsverhältnis von 1:3 aus, so bedeuten 10 Min.
> Druckzeit für einen "grossen Lappen", daß das Spoolfile 900 MByte gross ist,
> wenn USB tatsächlich der Flaschenhals sein sollte.
>
> Eine Fläche von 1 Quadratmeter bei 360 dpi hat aber je Grundfarbe ca.
> 200.000.000 Pixel (eigentlich mit 1 Bit Tiefe, da die Druckköpfe aber
> versetzt mehrfach die selben Ausgabepixel lasierend bedrucken gehen wir mal
> von 4 Bit Tiefe aus), was dann zu ca. 100 MByte je Grundfarbe führt, die
> sich bei 6 Farben zu satten 600 MByte zusammensummieren.
Wenn ich mich richtig entsinne, sieht es doch so aus:
USB 1.1 < Parallel (EPP) < 100BaseTx < FireWire < USB 2.0 < FireWire_800
Und SCSI noch irgendwo dazwischen, je nach Typ ;-)
> > und WinNT als RIP aus,
>
> Was spricht gegen NT? Die meisten PC-Kisten, die ich als Arbeitstiere in
> unserem Gewerbe so kenne, laufen fast ausschließlich unter NT4/SP6
> unauffällig und zufrieden stellend vor sich hin... und das wird wohl auch
> noch die nächsten Jahre so bleiben, jetzt wo es zum Glück auch keine Updates
> mehr gibt, die einem wahnsinnige Servicetechniker ungefragt einspielen :-)
Es spricht gar nichts gegen WIN NT, im Gegenteil. Nur hat eben NT keine
USB-Unterstützung ;-(
Deshalb ergeben sich folgende Möglichkeiten:
Anschluss Mac WINNT
USB 1.1 ja nein
Parallel nein ja
100BaseTx ja ja
USB 2 nein nein
> > parallel würde ich momentan bevorzugen,
>
> Und das ist schneller als USB Full-Speed?
Ja, schneller als USB 1.1. Außerdem ist mir der Anschluß am PC lieber,
da an der Kiste nur selten gearbeitet wird (ab und an mal ein cdr in EPS
konvertieren oder ein Word-Dokument belichten) und diese deshalb
ungestört vor sich hin rippen und drucken könnte ;-)
> > alternativ noch 100BaseTX, was ich aber bei der relativ langsamen
> > Druckausgabe eher für überflüssig halte ...
>
> Also ich kann mich noch an einen HP 1050 erinnern, vor dem ich fast heulend
> stand und zusehen durfte, wie der rasend schnell 70x100 Formproofs gedruckt
> hat. Ich hatte das Ausgabetempo eines 750C noch zu gut in Erinnerung mit dem
> ich kurz vorher die Freigabebögen für einige fette Verlagsvorschauen
> realiseren musste. Und da lagen Welten dazwischen. Wird wohl heutzutage eher
> noch flotter sein?
Bei den richtig teueren Modellen vermutlich schon ;-)
> Ich würde angesichts des Preises (damals immer so ca. 300 EUR Aufpreis für
> die LAN-fähigen Printserver) zur LAN-Variante neigen, da man dann einfach
> ein Eckchen flexibler ist. Und sei es nur, um mehr als ein RIP die Kiste
> bedienen zu lassen. Du musst ja auch bedenken, daß selbst ein GhostScript
> unter MacOS X völlig ausreicht, wenn man die ICC-Profilierung der Ausgabe
> über einen Publishing-Server (oder bspw. auch direkt per ColorSync) angeht.
> Es braucht ja nicht für alle Zwecke PosterShop, BestColor, GMG, GCS oder wie
> sie alle heissen...
Natürlich ist LAN die flexibelste Lösung; aber da man die
JetDirect-Karten jederzeit nachrüsten kann, könnte man ja mal vorsichtig
ohne LAN anfangen ...
Bjoern Seegebarth
> Achim Denzl schrieb am 06.02.2003 21:14 Uhr in
> <news:1fpz8bz.76zpnp1imuguaN%use...@dtpd.com>:
>
>
>>Apropos HP-Drucker: Möglicherweise steht demnächst die Anschaffung eines
>>DesignJet 500PS an. Hast Du (gute/schlechte) Erfahrung mit HP-LFPs?
>
Hi!
Falls es um den HP DesignJet 5000 PS geht, kann ich mich kurz einklinken.
Der steht hier im Rechenzentrum und druckte meine PDF DIN A0 in unter 15
minuten inclusive realtiv umfangreichem Druckkopftest.
(Via CUPS über einen UNIX-Server, Plotter angeschlossen über 100 MBit
Ethernet)
Der 1055 brauchte ca. doppelt so lange.
Grüße
Björn
Thomas Kaiser
<news:b26q3m$deb$04$1...@news.t-online.com>:
>> Achim Denzl schrieb am 06.02.2003 21:14 Uhr:
>>> Ich grüble gerade noch über die Anbindung nach: USB scheidet aufgrund von
>>> Geschwindigkeit ...
>>> und WinNT als RIP aus,
>>
> Wenn ich jetzt mal ausschließe, daß ich in der näheren Vergangenheit
> gaaanz Wesentliches verpaßt hab', dürfte die Kombination von NT und USB
> zum Scheitern verurteilt sein. NT 'kennt' kein USB.
Das ist doch egal?
Ich schaue mir die "limitierenden" Randbedigungen gerne einzeln an, d.h.
konkret USB 1.1 hier und WinNT da. IMO dürfte USB hinsichtlich Transfer der
zu druckenden Daten kein Flaschenhals sein (wenn komprimierte PCL-Streams
auf den Drucker geschoben werden) und NT hat sich als RIP-Plattform mehr als
bewährt (mal abgesehen von dem blöden Cache-Bug, den M$ wohl bis heute nicht
behoben hat <http://www.heise.de/ct/97/01/302/> und der ab und an Neustarts
als sinnvoll erscheinen lässt)
Das Problem USB <--> WinNT lässt sich doch durch den beherzten Griff in den
Wühltisch beim Verlassen bspw. des Blödiamarkts umschiffen. Kleine (billige)
PrintServer haben ja auch noch andere Vorteile.
Gruss,
Thomas
Thomas Kaiser
<news:1fq546j.1d2hn39r6aulkN%use...@dtpd.com>:
> In Falle des HP DJ 500PS wäre ein HP-eigenes Software-RIP für Mac und PC
> dabei;
Ein Software-RIP? Evtl. wieder so ein Rohrkerpierer wie PressReady mit dem
vor Jahren HPs verbundelt waren?
> das sollte es für den Anfang eigentlich tun, zumal in nächster
> Zeit damit sowieso nur Großfotos gedruckt werden und deshalb auch der
> Weg über TIFFs und den "normalen" Windows-Treiber ohne RIP möglich wäre.
Wenn denn der NT-Treiber ausreichende Qualität verspricht, dann schon.
Leider war es in der Vergangenheit oftmals so, daß die "nativen" Treiber für
NT nicht die Qualität der Treiber für die M$ Kinderzimmer-Varianten
brachten.
> Das Teil ist angeblich speziell für den unbeaufsichtigten Druck
> konzipiert,
Ah, d.h. also grosse Tintentanks? Das Gefrickel mit den Patronen für bspw.
die 750/755er erinnerte mich immer ein wenig an Homöopathie ;-)
> die Druckgeschwindigkeit mit 2,2 m2/h bei höchster Qualität eher niedrig.
"Bei höchster Qualität" impliziert aber auch immense Datenmengen...
[Schnittstellengeschwindigkeit]
> Wenn ich mich richtig entsinne, sieht es doch so aus:
> USB 1.1 < Parallel (EPP) < 100BaseTx < FireWire < USB 2.0 < FireWire_800
Also IMO stimmt die Wertung USB <--> Parallel nicht. Denn der Parallelport
ist ja in seiner Standardausführung schon mal eine extrem lahme Krücke. Mit
EPP/ECP schwingt er sich auf ca. 1,2 MBps hoch (wenn alle Randbedingungen
stimmen, was seltenst der Fall ist), was ja immer noch Welten von USB 1.1
entfernt ist (auch wenn man Netto/Brutto bei USB in Relation stellt)
Bzgl. 100BaseT ist anzumerken, daß das nur die reine LAN-seitige
Geschwindigkeit darstellt. Ich bin schon an interne Druckserver geraten,
deren wahre Limitation die interne Transferrate zum Druckercontroller war.
Es machte keinerlei Unterschied, ob man mit 10 oder 100 MBit/sek auf den
Drucker ging, weil die interne Schnittstelle grad mal 200 KByte/sek (also
ein Fünftel respektive Fünfzigstel der LAN-Schnittstellengeschwindigkeit)
hergab.
Das ist ein wenig so, wie wenn Festplattenhersteller in ihre Kataloge was
von 160 MByte/sek Durchsatz schreiben, nur weil die Platte einen U160
Anschluß hat ;-)
Die ganze Wertung der Schnittstellentechnologien bzgl. Geschwindigkeit führt
IMO in den Wald. Bei EPP/ECP (wenn das BIOS keine Macken hat, der Port, das
Kabel und der Drucker mitspielt, etc.) ist die Transfergeschwindigkeit noch
kalkulierbar, bei USB muss man schon genau gucken, wie die Transfers in
Abhängigkeit von Umgebungsparametern (wie der Anzahl Geräte am Bus bspw.) in
der Praxis aussehen. Bei allem darüber gilt das erst recht, v.a. wenn man im
Hinterkopf hat, daß die E/A-Schnittstellen in Druckern meistens als Module
ausgelegt sind, also die Schnittstelle zwischen der E/A Erweiterung und dem
internen RIP/Controller eigentlich eine genauere Betrachtung verdienen würde
(gibt die nämlich nur 200 KByte/sek her, wie bei dem Epson 9000, den ich mal
antestete, dann ist jegliche externe Schnittstelle "schnell" genug)
> Und SCSI noch irgendwo dazwischen, je nach Typ ;-)
Oh, gibt's sowas noch?
> Es spricht gar nichts gegen WIN NT, im Gegenteil. Nur hat eben NT keine
> USB-Unterstützung ;-(
Völlig egal. Es gibt Druckserver...
> Deshalb ergeben sich folgende Möglichkeiten:
>
> Anschluss Mac WINNT
> USB 1.1 ja nein
> Parallel nein ja
> 100BaseTx ja ja
> USB 2 nein nein
Abgesehen davon, daß "USB 2" durch "USB 2.0 Hi-Speed" ersetzt werden müsste,
damit irgend eine Aussagekraft entsteht, ist auch das IMO nicht weiter zu
berücksichtigen. Netzwerkfähigkeit und damit Schnittstellenunabhängigkeit
ist schnell und heutzutage auch günstig zu haben. Wenn man ein wenig auf
Komfort verzichtet, dann kann man auch Third-Party Produkte einsetzen und
einiges sparen.
>>> parallel würde ich momentan bevorzugen,
>>
>> Und das ist schneller als USB Full-Speed?
>
> Ja, schneller als USB 1.1.
USB 1.1 Low-Speed bedeutet 1,5 MBps, Full-Speed 12 MBps. EPP/ECP in der
schnellsten Ausführung liegt bei knapp über 1,2 MBps (wenngleich wohl
aufgrund des Overheads bei USB damit zu rechnen ist, daß eine *korrekt*
initialisierte ECP-Verbindung schneller sein dürfte als eine mit USB 1.1
Low-Speed). Aber Full-Speed müsste immer schneller sein ("müsste" weil es ja
auch Implementationsfehler, etc. gibt. Erinnert sich noch wer an die ersten
Quantum Fireballs, die mit SCSI-Interface deutlich langsamer waren als ihre
an sich identischen IDE-Schwesterchen?)
Gruss,
Thomas
Thomas Kaiser
<news:1fq4vps.lb21cqp3ixioN%use...@dtpd.com>:
> <Schwärm>
> Yep, XPress-Marken sind wohl eines der stärksten Features von XPress
Naja... das würde ich mal als Grundausstattung eines Layoutprogramms sehen,
daß es ein dokumentiertes neutrales Format neben seinem eigenen proprietären
versteht, um formatierte Texte zu ex- oder importieren.
BTW: Wenn man alles glaubt, was Quark in die Doku schreibt, dann fliegt man
böse auf die Nase. Der Import von Marken in Textrahmen per Apple Events
bspw. (bspw. um per AppleScript an der Cursorposition formatierten Text aus
Produktdatenbanken einfliessen zu lassen) funktioniert nicht (so, wie laut
Dokumentation)
> (Gibt's sowas eigentlich auch in InDesign?).
<Hüstel> Natürlich schon von Beginn an (heissen dort InDesign Tags -- seit
ID 2 natürlich auch alles als XML zu verpacken, wenngleich AFAIK noch
offiziell Beta)
Und wenn man partout mit Xpress-Marken arbeiten muss (bspw. weil einem
$DIENSTLEISTER für teuer Geld irgendwas mit Filemaker und Markenexport
programmiert hat), dann geht sogar das: <http://www.latenightsw.com/tagon/>
> Für eine unserer Publikationen erstellen wir regelmäßig einen Kalenderteil,
> der unter DOS (!) erfasst wird.
Nicht lachen: Soooo lange ist es auch noch nicht her, daß ich regelmässig
auf einem 8088 mit 4,77 MHz formatierte Texte erfasst habe (für Pagemaker
allerdings ;-)
> Ich habe ein RB-Programm gebastelt,
Das ist doch eher ein Fall für "Torquemada, the Inquisitor", *das*
unverzichtbare Handwerkszeug jedes Xpress-Textübernahme Profis?
> das den Output des DOS-Programm in XPress-Tags konvertiert, und mit wenigen
> Mausklicks ist das ganze Teil fertig. Früher eine Arbeit von etlichen
> Stunden, heute weniger als 5 Minuten.
Btw: Es gibt sowas auch als freie Perl-Module. So gibt es bspw. auch
Konverter von POD (Perl Online Dokumentation, eine IMO sehr leicht zu
handhabende Auszeichnungskonvention für Formatierungen in Texten) zu
Xpress-Marken. Und damit werden sogar Zeitschriften produziert!
<http://www.linux-magazin.de/Artikel/ausgabe/2001/04/perl/perl.html>
>>> Wobei ich das mit >1000 Seiten auch noch nicht probiert habe ...
>>
>> Ich schon... und ich habe eben irgendwann Routinen gebaut, die immer nur ein
>> paar hundert Seiten am Stück drucken...
>
> Spezielle Routinen? Das kann ich doch auch Drucken-Dialog vorgeben,
> 1-100, 101-200 etc. ...
Ich benutze Xpress aber so gut wie nie manuell sondern lasse es fernsteuern.
Und da muß man manches mal eben tatsächlich ein bisserl aufpassen, wenn man
bspw. bedenken muss, daß man immer Vorder-/Rückseite wegen Duplexdruck
(Xeikon) gleichzeitig schicken muss, bei Kapitelwechseln den Druckjob vorher
umbennen muss, weil sonst Chaos an der Druckmaschine entsteht (Benennung der
Spoolfiles anhand des %%Title Kommentars im PS-Job, der sich aus dem
Dokumenttitel in Xpress herleitet), etc. etc.
[Bildauflösung wann prüfen?]
> Genau das ist das Problem, Du hast eine Gleichung mit zwei unbekannten:
> Bildauflösung und Skalierung.
Genau. Und das ist zu einem bestimmten Zeitpunkt exakt eine zu viel.
> Ich löse das eben so, dass ich eine davon (nämlich die Bildauflösung) von
> vorne herein auf einen festen Wert setze. Dann ist nämlich nur noch die
> Skalierng im Layout-Programm maßgebend und evetuelle "Ausreißer" sind sofort
> sichtbar.
Und ich spar mir weiterhin die Zeit für den manuellen Aufwand und bastele
grade an einem Skript für Helios' scriptsrv, das direkt nach der Änderung
einer beliebigen Xpress-Datei auf dem Server aufgerufen wird und den Check
durchführt.
Während die in Villa Abajo noch manuell Bildauflösungen ändern, liegen die
in Villa Arriba bereits faul in der Sonne, werfen Tapas ein und lassen sich
mit Tinto de Verano zulaufen ;-)
> Leider ist die Seite von highwater.co.uk (das ist doch der Hersteller
> von Torrent?)
Highwater hat sich so vor 10 Jahren AFAIR nur einen Namen mit einer recht
effizienten JPEG-Kompressionsvariante gemacht (via Photoshop PlugIns und
Standalone Konvertern). Das Torrent wiederum ist nur ein beliebiges
Scriptworks Harlequin-OEM-Dingens...
> nicht sonderlich aussagekräftig. Hast du Erfahrungen mit Scriptworks-Updates,
> insbesondere Preise?
Hehe, hier in München gibt's ein kleines Systemhaus, die sehr viel Erfahrung
mit Harlequin RIPs haben (oder hatten, kein DNS-Eintrag mehr für deren
Domain vorhanden?!). Der Cheffe dort empfiehlt immer, in Hongkong zu kaufen,
da es nirgends billiger sei. Verstanden habe ich das zwar noch nie aber es
stimmt anscheinend... Bei Bedarf PM...
Gruss,
Thomas
Jochen Kremer
> Jochen Kremer schrieb am 10.02.2003 1:02 Uhr in
>
> Das ist doch egal?
Na dann ...:-)
> Ich schaue mir die "limitierenden" Randbedigungen gerne einzeln an, d.h.
> konkret USB 1.1 hier und WinNT da. IMO dürfte USB hinsichtlich Transfer der
> zu druckenden Daten kein Flaschenhals sein (wenn komprimierte PCL-Streams
> auf den Drucker geschoben werden) und NT hat sich als RIP-Plattform mehr als
> bewährt (mal abgesehen von dem blöden Cache-Bug, den M$ wohl bis heute nicht
> behoben hat <http://www.heise.de/ct/97/01/302/> und der ab und an Neustarts
> als sinnvoll erscheinen lässt)
Jaaaa, ich hab' ja auch weder 'was gegen NT noch gegen USB im
Allgemeinen. Nur in der Kombination wird's halt nix.
> Das Problem USB <--> WinNT lässt sich doch durch den beherzten Griff in den
> Wühltisch beim Verlassen bspw. des Blödiamarkts umschiffen. Kleine (billige)
> PrintServer haben ja auch noch andere Vorteile.
Wenn man sich dann sonst keine Probleme einhandelt, mag das gehen.
Jedenfalls entsteht der Mehraufwand, diese neue Kombination auszutesten,
ob auch alles das läuft, was laufen soll. Wenn ausschließlich PCL- bzw.
Postscript-Daten geschaufelt werden sollen, wird's wohl klappen. Ob
jedoch gewisse Status-, Wartungs- oder Einstellungsoptionen
funktionieren, bleibt fraglich oder muß mit Mehraufwand anders geregelt
werden.
Schöne Grüße
Jochen
Achim Denzl
> Achim Denzl schrieb am 10.02.2003 1:18 Uhr in
> <news:1fq546j.1d2hn39r6aulkN%use...@dtpd.com>:
>
> > In Falle des HP DJ 500PS wäre ein HP-eigenes Software-RIP für Mac und PC
> > dabei;
>
> Ein Software-RIP? Evtl. wieder so ein Rohrkerpierer wie PressReady mit dem
> vor Jahren HPs verbundelt waren?
Es dürfte das Gleiche sein, das zur Zeit auch dem relativ neuen und
genialen DesignJet 10ps beiliegt. Wir haben das mal auf einem WIN
NT-Rechner laufen gehabt (weil so lange Lieferzeit auf das BEST-RIP war
;-) und es macht auch auf dem Mac einen brauchbaren Eindruck.
> > das sollte es für den Anfang eigentlich tun, zumal in nächster
> > Zeit damit sowieso nur Großfotos gedruckt werden und deshalb auch der
> > Weg über TIFFs und den "normalen" Windows-Treiber ohne RIP möglich wäre.
>
> Wenn denn der NT-Treiber ausreichende Qualität verspricht, dann schon.
> Leider war es in der Vergangenheit oftmals so, daß die "nativen" Treiber für
> NT nicht die Qualität der Treiber für die M$ Kinderzimmer-Varianten
> brachten.
Die vorliegenden Probedrucke sehen vielversprechend aus. Momentan haben
wir noch eine eigene Testdatei an HP geschickt, mal sehen, wie die dann
aussieht ...
> > Das Teil ist angeblich speziell für den unbeaufsichtigten Druck
> > konzipiert,
>
> Ah, d.h. also grosse Tintentanks? Das Gefrickel mit den Patronen für bspw.
> die 750/755er erinnerte mich immer ein wenig an Homöopathie ;-)
Das sind die gleichen 69ml-Patronen wie beim DJ 10ps. Und nachdem dieser
(bei unserem Kunden) locker 500 A4-Seiten (Vollfläche Farbe!) schafft,
bevor die Teilchen am Ende sind, und das rechnerisch ca. 30 A0-Drucken
entspricht, ist das durchaus ok. Dann ist eh die Rolle am Ende ;-)
> > die Druckgeschwindigkeit mit 2,2 m2/h bei höchster Qualität eher niedrig.
>
> "Bei höchster Qualität" impliziert aber auch immense Datenmengen...
Jo. Mal sehen, oft tut's ja auch die zweitbeste Qualität, optisch kaum
unterscheidbar, aber doppelt so schnell ;-)
> [Schnittstellengeschwindigkeit]
> > Wenn ich mich richtig entsinne, sieht es doch so aus:
> > USB 1.1 < Parallel (EPP) < 100BaseTx < FireWire < USB 2.0 < FireWire_800
>
> Also IMO stimmt die Wertung USB <--> Parallel nicht. Denn der Parallelport
> ist ja in seiner Standardausführung schon mal eine extrem lahme Krücke. Mit
> EPP/ECP schwingt er sich auf ca. 1,2 MBps hoch (wenn alle Randbedingungen
> stimmen, was seltenst der Fall ist), was ja immer noch Welten von USB 1.1
> entfernt ist (auch wenn man Netto/Brutto bei USB in Relation stellt)
Ich zitiere mal aus <http://www.usb.org/faq/ans2>:
Q2: How does this compare to other connections used with PCs and
workstations?
A2: Here's a quick list of the maximum transfer rates for various
connections in megabits (Mb) and megabytes (MB) per second:
serial port: 115kbits/s (.115Mbits/s)
standard parallel port: 115kBYTES/s (.115MBYTES/s)
Original USB: 12Mbits/s (1.5MBYTES/s)
ECP/EPP parallel port: 3MBYTES/s
IDE: 3.3-16.7MBYTES/s
SCSI-1: 5MBYTES/s
SCSI-2 (Fast SCSI, Fast Narrow SCSI): 10MBYTES/s
Fast Wide SCSI (Wide SCSI): 20MBYTES/s
Ultra SCSI (SCSI-3, Fast-20, Ultra Narrow): 20MBYTES/s
UltraIDE: 33MBYTES/s
Wide Ultra SCSI (Fast Wide 20): 40MBYTES/s
Ultra2 SCSI: 40MBYTES/s
IEEE-1394: 100-400Mbits/s (12.5--50MBYTES/s)
Hi-Speed USB: 480Mbits/s
Wide Ultra2 SCSI: 80MBYTES/s
Ultra3 SCSI: 80MBYTES/s
Wide Ultra3 SCSI: 160MBYTES/s
FC-AL Fiber Channel: 100-400MBYTES/s
> > Es spricht gar nichts gegen WIN NT, im Gegenteil. Nur hat eben NT keine
> > USB-Unterstützung ;-(
>
> Völlig egal. Es gibt Druckserver...
>
> > Deshalb ergeben sich folgende Möglichkeiten:
> >
> > Anschluss Mac WINNT
> > USB 1.1 ja nein
> > Parallel nein ja
> > 100BaseTx ja ja
> > USB 2 nein nein
>
> Abgesehen davon, daß "USB 2" durch "USB 2.0 Hi-Speed" ersetzt werden müsste,
> damit irgend eine Aussagekraft entsteht, ist auch das IMO nicht weiter zu
> berücksichtigen. Netzwerkfähigkeit und damit Schnittstellenunabhängigkeit
> ist schnell und heutzutage auch günstig zu haben. Wenn man ein wenig auf
> Komfort verzichtet, dann kann man auch Third-Party Produkte einsetzen und
> einiges sparen.
Schon klar. Es geht ja nur darum, ob die Mehrkosten irgendwie Sinn
machen ...
> >>> parallel würde ich momentan bevorzugen,
> >>
> >> Und das ist schneller als USB Full-Speed?
> >
> > Ja, schneller als USB 1.1.
>
> USB 1.1 Low-Speed bedeutet 1,5 MBps, Full-Speed 12 MBps. EPP/ECP in der
> schnellsten Ausführung liegt bei knapp über 1,2 MBps (wenngleich wohl
> aufgrund des Overheads bei USB damit zu rechnen ist, daß eine *korrekt*
> initialisierte ECP-Verbindung schneller sein dürfte als eine mit USB 1.1
> Low-Speed). Aber Full-Speed müsste immer schneller sein ("müsste" weil es ja
> auch Implementationsfehler, etc. gibt. Erinnert sich noch wer an die ersten
> Quantum Fireballs, die mit SCSI-Interface deutlich langsamer waren als ihre
> an sich identischen IDE-Schwesterchen?)
Ach ja, die Bits und Bytes. Wenn ich die Tabelle von usb.org richtig
interpretiere, liegt USB 1.1 bei 12 MBIT/sek., Parallel (EPP/ECP) bei 3
MBYTE/sek. was wiederum 24 MBIT/sek. entspricht. Das würde dann FÜR
Parallel sprechen.
Achim Denzl
> > Ich habe ein RB-Programm gebastelt,
>
> Das ist doch eher ein Fall für "Torquemada, the Inquisitor", *das*
> unverzichtbare Handwerkszeug jedes Xpress-Textübernahme Profis?
Genau so lief das früher. Allerdings war der Weg umständlicher als mit
dem RB-Programm:
- DOS-Diskette mittels uraltem "Dateien konvertieren" konvertieren
- Mittels BBEdit die Einzeldateien "concatenaten"
- Mit Torquemada die grundlegenden Tags einbauen
- Alle Daten händisch von "01.03.1999" auf "Montag 01" ändern ;-)
- Text in Xpress importieren und falsche Tags ausbessern
Das geht jetzt alles auf einmal, it's just one click ;-)
> > das den Output des DOS-Programm in XPress-Tags konvertiert, und mit wenigen
> > Mausklicks ist das ganze Teil fertig. Früher eine Arbeit von etlichen
> > Stunden, heute weniger als 5 Minuten.
>
> Btw: Es gibt sowas auch als freie Perl-Module. So gibt es bspw. auch
> Konverter von POD (Perl Online Dokumentation, eine IMO sehr leicht zu
> handhabende Auszeichnungskonvention für Formatierungen in Texten) zu
> Xpress-Marken. Und damit werden sogar Zeitschriften produziert!
> <http://www.linux-magazin.de/Artikel/ausgabe/2001/04/perl/perl.html>
Das werde ich mir bei Gelegenheit mal anschauen (heute schon zu müde).
> >>> Wobei ich das mit >1000 Seiten auch noch nicht probiert habe ...
> >>
> >> Ich schon... und ich habe eben irgendwann Routinen gebaut, die immer
> >> nur ein paar hundert Seiten am Stück drucken...
> >
> > Spezielle Routinen? Das kann ich doch auch Drucken-Dialog vorgeben,
> > 1-100, 101-200 etc. ...
>
> Ich benutze Xpress aber so gut wie nie manuell sondern lasse es fernsteuern.
Spielkind ;-)))
> [Bildauflösung wann prüfen?]
> > Genau das ist das Problem, Du hast eine Gleichung mit zwei unbekannten:
> > Bildauflösung und Skalierung.
>
> Genau. Und das ist zu einem bestimmten Zeitpunkt exakt eine zu viel.
>
> > Ich löse das eben so, dass ich eine davon (nämlich die Bildauflösung) von
> > vorne herein auf einen festen Wert setze. Dann ist nämlich nur noch die
> > Skalierng im Layout-Programm maßgebend und evetuelle "Ausreißer" sind sofort
> > sichtbar.
>
> Und ich spar mir weiterhin die Zeit für den manuellen Aufwand und bastele
> grade an einem Skript für Helios' scriptsrv, das direkt nach der Änderung
> einer beliebigen Xpress-Datei auf dem Server aufgerufen wird und den Check
> durchführt.
Auch nett ;-)
> Während die in Villa Abajo noch manuell Bildauflösungen ändern, liegen die
> in Villa Arriba bereits faul in der Sonne, werfen Tapas ein und lassen sich
> mit Tinto de Verano zulaufen ;-)
Um wieder etwas onTopic zu werden: So lange Du Dir nicht mal
versehentlich einen TOPAZ einwirfst ... [SCNR]
> > Leider ist die Seite von highwater.co.uk (das ist doch der Hersteller
> > von Torrent?)
>
> Highwater hat sich so vor 10 Jahren AFAIR nur einen Namen mit einer recht
> effizienten JPEG-Kompressionsvariante gemacht (via Photoshop PlugIns und
> Standalone Konvertern). Das Torrent wiederum ist nur ein beliebiges
> Scriptworks Harlequin-OEM-Dingens...
Das heißt, die Updates krieg ich dann wohl nur beim "offiziellen"
Hersteller (in meinem Fall STORM, ziemlich wackelig seit einiger Zeit)?
> > nicht sonderlich aussagekräftig. Hast du Erfahrungen mit
> > Scriptworks-Updates, insbesondere Preise?
>
> Hehe, hier in München gibt's ein kleines Systemhaus, die sehr viel Erfahrung
> mit Harlequin RIPs haben (oder hatten, kein DNS-Eintrag mehr für deren
> Domain vorhanden?!). Der Cheffe dort empfiehlt immer, in Hongkong zu kaufen,
> da es nirgends billiger sei. Verstanden habe ich das zwar noch nie aber es
> stimmt anscheinend... Bei Bedarf PM...
Da komme ich evtl. noch darauf zurück.
Achim Denzl
> Falls es um den HP DesignJet 5000 PS geht, kann ich mich kurz einklinken.
> Der steht hier im Rechenzentrum und druckte meine PDF DIN A0 in unter 15
> minuten inclusive realtiv umfangreichem Druckkopftest.
>
> (Via CUPS über einen UNIX-Server, Plotter angeschlossen über 100 MBit
> Ethernet)
>
> Der 1055 brauchte ca. doppelt so lange.
Danke für die Info, allerdings geht es wirklich nur um den "kleinen"
Bruder DesignJet 500ps ...
Bjoern Seegebarth
>
> Danke für die Info, allerdings geht es wirklich nur um den "kleinen"
> Bruder DesignJet 500ps ...
>
Hi!
Achso.
Den kannte ich noch gar nicht. :-)
Grüße
Björn
Thomas Kaiser
<news:1fq6vog.12ee5umfrtifcN%use...@dtpd.com>:
> Ich zitiere mal aus <http://www.usb.org/faq/ans2>:
>
> A2: Here's a quick list of the maximum transfer rates
Hmm... "maximum" ist ziemlich dehnbar... Zumal bei ECP drei Gerätschaften
(Rechner-Port, Kabel, Drucker-Port) optimal aufeinander abgestimmt sein
müssen und andere Randbedingungen (BIOS-Fehler bzw. -Einstellungen bspw.,
Treiber) auch noch stimmen müssen. Andernfalls erfolgt sehr früh schon ein
Fallback auf langsamere Methoden.
> Original USB: 12Mbits/s (1.5MBYTES/s)
Die in der Praxis erreichbaren Datenraten dürften deutlich drunter liegen --
zumindest nach meinen bisherigen Erfahrungen (siehe die vorsichtigen
Schätzungen, die ich bisher in dem Thread absonderte)
> ECP/EPP parallel port: 3MBYTES/s
3 gleich? Oha...
> Ach ja, die Bits und Bytes.
Hehe, genau das ist mir entfallen, daß parallel und seriell einen
substantiellen Unterschied beinhalten ;-)
> Wenn ich die Tabelle von usb.org richtig interpretiere, liegt USB 1.1 bei
> 12 MBIT/sek., Parallel (EPP/ECP) bei 3 MBYTE/sek. was wiederum 24 MBIT/sek.
> entspricht. Das würde dann FÜR Parallel sprechen.
"Würde" mal wieder. Von dem her, was maximal möglich ist, würde ich auch
zustimmen. Aber das "müsste" man sich IMO erst mal in der Praxis ansehen,
was bei einer bestimmten Kombination Port <--> Kabel <--> Port letzten Endes
rauskommt.
Ich habe mir vorhin nochmals die verschiedenen IEEE 1284 Modi kurz zu Gemüte
geführt (<http://www.fapo.com/1284int.htm>). Schon ziemlich erstaunlich, daß
so etwas Altehrwürdiges wie der Parallelport diese Komplexität aufweisen
kann ;-)
Gruss,
Thomas, erstaunt über unser beider OT-Verlässlichkeit =8-|
Achim Denzl
> > Danke für die Info, allerdings geht es wirklich nur um den "kleinen"
> > Bruder DesignJet 500ps ...
> >
> Hi!
>
> Achso.
> Den kannte ich noch gar nicht. :-)
Der ist wohl auch ziemlich neu und einfach deshalb interessant, weil er
nur ca. 1/3 des 5000er kostet.
Achim Denzl
[Vergleich von Portgeschwindigkeiten]
> "Würde" mal wieder. Von dem her, was maximal möglich ist, würde ich auch
> zustimmen. Aber das "müsste" man sich IMO erst mal in der Praxis ansehen,
> was bei einer bestimmten Kombination Port <--> Kabel <--> Port letzten Endes
> rauskommt.
Eben. Und da der Parallel-Port schon mal da ist, mache ich wohl damit
den Anfang. Wenn's mir dann zu langsam erscheint, nehmen wir mal USB
(RIP dann auf Mac) und wenn's dann immer noch hakt, riskiere ich doch
einen Blick auf die (aufpreispflichtige) LAN-Anbindung.
> Gruss,
>
> Thomas, erstaunt über unser beider OT-Verlässlichkeit =8-|
Und ich bemitleide schon mal die Mac-Newbies, die verzweifelt nach dem
Parallel-Port suchen ;-)